- Access Token의 유효기간은 짧다.
(ex. 60일(마이크로소프트), 1시간(아마존))
- Refresh Token의 유효기간은 길다.
(ex. 1년 (마이크로소프트))
Access Token
유저 인증용으로 사용 (짧은 만료 시간)
서버는 보통 Access Token 자체는 저장하지 않음
만료되면 재로그인 or Refresh Token으로 재발급
Refresh Token
Access Token 갱신용 (만료 시간 김)
서버 or Redis 등에 저장 (보안적으로 중요함)
탈취되면 Access Token을 계속 재발급받을 수 있음 ❗
- 평소에 API 통신할 때는 Access Token을 사용하고, Refresh Token은 Access Token이 만료되어 갱신될 때만 사용한다.
즉, 통신과정에서 탈취당할 위험이 큰 Access Token의 만료 기간을 짧게 두고 Refresh Token으로 주기적으로 재발급함으로써 피해을 최소화한 것이다.
구체적으로 살펴보기 (서버-클라이언트 통신)
-
로그인 인증에 성공한 클라이언트는 Refresh Token과 Access Token 두 개를 서버로부터 받는다.
-
클라이언트는 Refresh Token과 Access Token을 로컬에 저장해놓는다.
-
클라이언트는 헤더에 Access Token을 넣고 API 통신을 한다. (Authorization)
-
일정 기간이 지나 Access Token의 유효기간이 만료되었다.
-
Access Token은 이제 유효하지 않으므로 권한이 없는 사용자가 된다.
-
클라이언트로부터 유효기간이 지난 Access Token을 받은 서버는 401 (Unauthorized) 에러 코드로 응답한다.
-
401를 통해 클라이언트는 invalid_token (유효기간이 만료되었음)을 알 수 있다.
-
헤더에 Access Token 대신 Refresh Token을 넣어 API를 재요청한다.
-
Refresh Token으로 사용자의 권한을 확인한 서버는 응답쿼리 헤더에 새로운 Access Token을 넣어 응답한다.
-
만약 Refresh Token도 만료되었다면 서버는 동일하게 401 error code를 보내고, 클라이언트는 재로그인해야한다.
결론
-
Refresh Token은 JWT 토큰의 탈취 위험을 최소화하고, 사용자 경험을 높이기 위해(빈번한 재로그인 방지를 위해) 나온 것이다.
-
Access Token의 유효 기간은 짧고, 평소 API 통신할 때 사용한다.
-
Refresh Token의 유효 기간은 길고, Access Token 재발급 받을 때 사용한다.
-
Refresh Token은 여전히 탈취 위험이 있고, Refresh Token Rotation을 통해 위험을 줄일 수 있다.
