프로젝트를 본격적으로 들어가기전 ! 토큰 사용을 조금 유기적으로 해보기 위해 JWT 토큰에 대해 알아봤다.
Access Token
발급된 이후, 서버에 저장되지 않고 토큰 자체 사용자 권한을 인증한다.
만약, Access Token이 탈취되면 토큰 만료 전까지 토큰을 획득한 사람은 누구나 접근이 가능하다.
JWT는 발급한 후 삭제가 불가능하다. 때문에 토큰에 유효시간을 부여하는 식으로 탈취 문제에 대응하여야한다.
토큰 탈취 문제에 대응하고자 유효시간을 짧게 유지한다면 유저에게 굉장히 불편한 경험을 줄 수 있다.
토큰의 유효시간이 짧아진만큼 사용자는 로그인을 자주해 새롭게 토큰을 받아야하기때문에..
사용자에게 불편한 경험을 주지 않고자 유효시간을 늘려버리면 토큰을 탈취당했을 때 보안이 취약해지게 된다.
이러한 단점을 보완하고자 한게 Refresh Token이다.
- Acees Token : 접근에 관여하는 토큰
- Refresh Token : 재발급에 관여하는 토큰
Access / Refresh Token 재발급 원리
1. 로그인 시에 Access Token 과 Refresh Token을 모두 발급한다.
Refresh Token은 서버 DB에 저장(Access Token은 서버에 저장되지 않음), 클라이언트 측에서는 Refresh Token 과 Access Token을 쿠키, 세션스토리지, 로컬스토리지 등에 저장한다.
요청이 있을 때 마다 두가지 토큰을 모두 헤더에 담아서 서버에 보낸다.
2. 사용자가 인증이 필요한 API에 접근하고자 하면, 서버에서는 가장 먼저 토큰을 검사한다.
경우 1. Access Token , Refresh Token 모두 만료 -> 에러, 재로그인 요청
경우2. Access Token 만료, Refresh Token 유효 -> Refresh Token 검증하여 (서버 DB에 저장되어 토큰과 클라이언트에 저장되어있는 토큰을 비요하여) Access Token 발급
경우3. Access Token 유효, Refresh Token 만료 -> Access Token 검증하여 Refresh Token 재발급(access token이 유효하다 ==이미 인증되었다 -> 바로 refresh token 재발급)
경우4. Access Token , Refresh Token 모두 유효 -> 정상처리
3. 로그아웃시 모든 토큰을 만료시킴
ref
https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Access-Token-Refresh-Token-%EC%9B%90%EB%A6%AC-feat-JWT
