[231116] Access Token과 Refresh Token

Access Token의 문제점

 

• 제 3자에게 탈취당할 경우 보안에 취약
  • 발급된 이후 서버에 저장되지 않고 토큰 자체로 검증하여 사용자 권한을 인증하기 때문에  탈취된 경우 토큰이 만료되기 전까지 토큰을 획득한 사람은 누구나 권한 접근이 가능해짐
  • JWT는 발급 후 삭제가 불가능하기 때문에 토큰에 유효기간을 부여하는 식으로 탈취 문제에 대응
• 유효기간이 짧으면 토큰 남용을 방지할 수 있지만 그만큼 사용자는 로그인을 자주해서 토큰을 발급받아야 함

 

Refresh Token

 

• 형태는 Access Token과 같은 JWT이거나 혹은 간단한 문자열 또는 UUID일 수 있음
• Access Token은 접근에 관여하는 토큰이고 Refresh Token은 재발급에 관여하는 토큰
• 로그인 성공했을 때 서버는 Access Token과 Refresh Token을 동시에 발급
• 서버는 데이터베이스에 Refresh Token을 저장하고 클라이언트는 둘 다 헤더에 담아 요청을 보냄
  • 서버에서 Refresh Token을 제어할 수 있음. 탈취당한 상황에서 토큰을 무효화 가능.
• Refresh Token은 긴 유효기간을 가지면서 Access Token이 만료되었을 때 새로 재발급해주는 열쇠가 됨
• 클라이언트가 만료된 Access Token을 서버에 보내면 서버는 Refresh Token이 DB에 있는지 비교하고 일치하면 다시 Access Token을 발급
• 사용자가 로그아웃을하면 서버는 저장소에서 Refresh Token을 삭제

 

Refresh Token의 한계

 

• 틸취된 Access Token을 만료시킬 수 없음
• Refresh Token 자체를 탈취 당할 가능성

 

Refresh Token 전략들

 

• RTR(Refresh Token Rotation) 전략
  • Refresh API 사용 시, Access Token과 Refresh Token을 갱신시켜버리는 방식
  • Refresh Token을 1회용으로 구현
  • XSS 취약점을 이용한 공격을 막지 못함
•  Refresh Token에 http-only 적용 전략
  • http only 옵션을 사용해 리프레시 토큰을 쿠키로 보냄으로써 XSS 공격을 예방
  • 하지만 csrf을 사용하면 탈취 가능
• 사용자 정보를 Access Token에 저장
  • 발급 당시 IP, 기기/브라우저 정보를 저장하고 엑세스 토큰을 사용하는 사람의 정보와 크게 다르면 재로그인을 수행

 

참고 블로그

 

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Access-Token-Refresh-Token-%EC%9B%90%EB%A6%AC-feat-JWT

🌐 Access Token & Refresh Token 원리

https://hudi.blog/refresh-token/

Access Token의 문제점과 Refresh Token

https://puleugo.tistory.com/154

Refresh Token을 사용하는 이유(Feat. Redis)