AccessToken은 로그인 할 때 발급되는 것이었다. 만약에 AccessToken을 누가 탈취해 갔다면 탈취한 사람이 계속해서 나의 서비스를 이용할 수 있을 것이다. 그래서 AccessToken은 만료 기간을 짧게 하는데 그럼 AccessToken을 발급받으려고 계속해서 로그인을 반복해야한다. 그래서 나온 것이 RefreshToken이다. RefreshToken은 유효 기간을 길게해서 만료 기간이 짧은 AccessToken이 만료 됐을 시 AccessToken을 발급하기 위한 자격 증명 토큰이다.

그럼 첫번째 의문이 든다. RefreshToken도 탈취하면..? 계속해서 RefreshToken으로 AccessToken을 받을 수 있는 게 아닌가? 이 때 필요한게 RefreshToken도 AccessToken을 재발급 할 때마다 다시 발급하는 RTR(Refresh Token Rotation)방식이다. 그럼 이어서 만료 시간까지는 RefreshToken을 또 사용할 수 있는 거 아닐까? 할때 필요한게 db or redis이다.

만약 A와 B라는 사용자가 있다고 했을 때, B가 A의 RefreshToken으로 AccessToken을 먼저 발급 받았다. 그 이후에 다시 A가 RefreshToken으로 AccessToken 재발급을 요청한다면, db/redis에 이전의 RefreshToken이 없으니까(화이트 리스트 방식이라면) 이미 사용된 RefreshToken이 다시 사용되었다는 것을 알 수있다. A가 먼저 RefreshToken을 사용한다면 이전의 RefreshToken이 사라지고 새 RefreshToken이 db/redis에 저장되니까(화이트 리스트 방식이라면), B는 그 RefreshToken을 이용할 수 없게된다. 이렇게 RefreshToken을 저장하는 공간이 db/redis이다. 만약 이 공간이 없다면, RefreshToken을 이미 쓴 건지, 사용자가 로그아웃을 한건지 알 수 없다. 그래서 탈취된 RefreshToken의 사용을 만료 시간까지 중지할 방법이 없을 것이다.

정리하자면 RefreshToken이 있는 이유는 AccessToken의 유효 기간을 짧게 하기 위해서 RTR을 쓰는 이유는 RefreshToken이 탈취 됐을 때 피해를 최소화 하기 위해서 db/redis 저장공간을 쓰는 이유는 RTR로 이미 소비된 토큰인지 관리하기 위해서, RefreshToken이 만료 되기 전에 로그아웃을 했을 때 생기는 상태를 관리하기 위해서이다.

최종 수정일: 2026-06-24

@하진 Hajin’s Portfolio

📧 contact [email protected]