JWT access token refresh token 구조는 로그인 구현에서 자주 등장합니다. 하지만 단순히 토큰을 두 개 만든다고 자동으로 안전해지는 것은 아닙니다.
핵심은 API 접근에 쓰는 짧은 권한과 로그인 유지에 쓰는 긴 권한을 분리하는 것입니다. 이 글은 JWT 표준과 OAuth 보안 권고, OWASP 자료를 기준으로 access token과 refresh token을 나누는 이유를 정리합니다.
JWT access token refresh token을 먼저 한 줄로 나누면
access token은 API에 접근할 때 권한을 증명하는 짧은 수명의 토큰입니다. refresh token은 access token이 만료됐을 때 새 access token을 받기 위한 더 긴 수명의 토큰입니다.
login
-> access token issued
-> refresh token issued
API request
-> use access token
access token expired
-> use refresh token to issue a new access token이렇게 나누면 매 요청마다 긴 수명의 권한을 보내지 않아도 되고, access token이 유출됐을 때 피해 시간을 줄일 수 있습니다.
access token은 짧게, 자주 검증한다
access token은 API 서버가 사용자의 권한을 확인하는 데 쓰입니다. 그래서 일반적으로 만료 시간을 짧게 두고, 요청마다 signature, issuer, audience, expiration 같은 값을 검증합니다.
짧은 만료 시간은 사용자를 귀찮게 만들 수 있습니다. refresh token은 이 불편함을 줄이기 위해 등장합니다. access token이 끝나도 사용자가 매번 비밀번호를 다시 입력하지 않도록 돕습니다.
refresh token은 더 위험한 권한이다
refresh token은 새 access token을 받을 수 있는 권한이므로 더 조심스럽게 다뤄야 합니다. 공격자가 refresh token을 얻으면 access token을 반복해서 재발급받을 수 있기 때문입니다.
- 저장 위치를 신중하게 정한다
- 재발급 요청에서 refresh token 유효성을 서버가 확인한다
- 가능하면 rotation으로 이전 refresh token을 폐기한다
- 탈취가 의심되면 token family 전체를 무효화한다
- 로그아웃과 비밀번호 변경 시 refresh token 폐기 정책을 둔다
JWT라고 해서 무조건 서버 상태가 없는 것은 아니다
JWT는 자체적으로 claim을 담고 서명 검증이 가능하지만, refresh token 폐기, rotation, 강제 로그아웃까지 구현하려면 서버 쪽 상태가 필요해지는 경우가 많습니다.
JWT를 쓰면 세션 저장소가 완전히 필요 없어진다는 말은 과한 단정입니다. 특히 refresh token을 안전하게 운영하려면 저장, 폐기, 재사용 탐지 정책이 함께 있어야 합니다.
실무 체크리스트
- access token 만료 시간을 짧게 두는 이유를 팀 기준으로 정한다
- refresh token 저장 위치와 전송 방식을 명확히 한다
- 재발급 시 rotation과 재사용 탐지를 검토한다
- 로그아웃, 기기 분실, 비밀번호 변경 시 폐기 정책을 둔다
- 토큰에 민감한 개인정보를 넣지 않고 필요한 claim만 담는다
정리
JWT access token refresh token를 이해할 때는 문법이나 기능 이름보다 문제가 생기는 경계를 먼저 보는 편이 좋습니다. 오늘 글의 기준은 ‘언제 다시 실행되고, 어디까지 공개되고, 어떤 권한이 남는가’처럼 실수 지점을 분리하는 것입니다.
함께 보면 좋은 내부 글은 Spring Security JWT 로그인은 어떻게 흘러갈까, OAuth2 소셜 로그인 후 JWT 발급 구조, Spring Security 401과 403 차이입니다. 외부 기준은 RFC 7519 – JSON Web Token, OAuth 2.0 Security Best Current Practice, OWASP Session Management Cheat Sheet를 확인했습니다.
