Access Token 과 Refresh Token

JWT 를 공부하면서 Access Token 과 Refresh Token 의 흐름에 대해 이해한 내용을 기록하고자 한다.

 

먼저 사용자가 로그인을 시도하면 클라이언트에서 사용자 인증을 위해 서버로 ID 와 PASSWORD 등의 데이터를 보내 인증 요청을 한다.

 

서버에서는 클라이언트가 요청한 데이터를 여러 검증을 거쳐 jwt Token 을 응답하게 된다.

 

이 때, 서버는 두개의 토큰을 클라이언트로 전달하는데 이때 전송되는 Token 이 바로 Access Token 과 Refresh Token 이다.

 

1. Access Token (생명 주기 : 10min ~ 1hour)

- Access Token 은 사용자의 요청을 인증하기 위해 클라이언트에서 자주 사용되며, 상대적으로 짧은 시간 동안만 유효하도록 설계한다.

- Token 이 탈취되었을 경우 짧은 유효 기간 덕분에 피해를 최소화 할 수 있다.

 

2. Refresh Token (생명 주기 : ~ 8hour)

- Access Token 보다 더 긴 기간 동안 유효하고, 일반적으로 Secure, HttpOnly 쿠키에 저장된다. 이 토큰은 사용자가 로그아웃하거나 만료될 때까지 변경되지 않으며, 서버에 저장된 것과 대조하여 검증된다.

- Refresh Token 은 민감도가 높기 때문에 가능한 자주 사용하지 않는 것이 좋다.

 

전체적인 Jwt Token 을 발급된 시점부터 만료 시점까지를 정리해보면

 

사용자가 로그인을 시도하면 서버에서는 두 개의 토큰(Access, Refresh)을 전달하고 클라이언트(브라우저)는 해당 토큰의 암호화된 토큰 데이터를 각각 로컬스토리지 또는 세션스토리지(Access Token)와 쿠키(Refresh Token)에 저장한다.

 

Access Token 은 비교적 짧은 생명주기를 가진다 (10min ~ 1hour) 

사용자는 발급받은 Access Token 을 통해 해당 어플리케이션의 사용 권한을 가지게 되고 계속 사용하다가 만료 시간이 되면 다시 서버에게 토큰을 재발급 해달라는 요청을 보낸다.

 

이 때 토큰을 재발급 받기 위해서 기존에 응답받은 쿠키에 저장 되어 있는 Refresh Token 의 정보를 서버로 보내게 되는데 서버에서 이 Refresh 토큰의 검증을 통해 다시 클라이언트로 새로운 Access Token 을 보내준다.

 

(OAuth 2.0 에서 Access Token 의 기본 권장 유효 기간은 1시간으로 되어 있지만 민감한 시스템에서는 10~15분으로 더 짧게 커스텀 하는 경우도 있다)

Access Token 권장 생명 주기 = 출처 : https://cloud.google.com/apigee/docs/api-platform/security/oauth/access-tokens?hl=ko

 

두 번째로 발급받은 Access Token  만료 되면 클라이언트는 다시 서버로 리플래시 토큰과 함께 새로운 Access Token 의 정보를 요청하고 서버는 refresh Token 의 만료 정보를 확인하고 만료가 되지 않았다면 새로운 Access Token 을 클라이언트로 전달하고 (refresh Token 의 만료 전까지는 계속해서 이 로직을 반복) 만약, refresh Token 의 생명주기가 만료 되었다면 서버는 클라이언트에게 재 로그인 요청을 하게 된다.