🎈 Refresh Token
- Access Token은 발급된 이후 서버에 저장되지 않고 토큰 자체로 검증을 하며 사용자 권한을 인증하기 때문에 Access Token이 탈취되면 토큰이 만료되기 전까지 토큰을 가진 사람은 누구나 접근이 가능해진다.
- JWT는 발급 후 삭제가 불가, 유효시간을 부여하는 식으로 대응을 해야한다.
- 유효시간을 짧게 할 경우, 토큰을 새롭게 받아야 하는 빈도가 늘어나므로 불편하다
- 불편을 해결하기 위해 길게 할 경우, 탈취의 위험성이 증가한다.
그에 대한 답이 바로 Refresh Token!!
👛 똑같은 JWT
- Access Token은 접근에 관여하는 토큰, Refresh Token은 재발급에 관여하는 토큰일 뿐 역할만 다른 JWT
🎁 재발급의 원리
1. 로그인 시 Access Token과 Refresh Token을 모두 발급한다.
📍 이 때 Refresh Token만 서버측 DB에 저장하며, Refresh Token과 Access Token을 쿠키 혹은 웹스토리지에 저장
2. 인증 API 접근 시, 가장 먼저 토큰을 검사한다.
- 토큰을 검사함과 동시에 각 경우에 대해서 토큰의 유효기간을 확인하여 재발급 여부를 결정한다.
📝 case1 : access token과 refresh token 모두가 만료된 경우 → 에러 발생 (재 로그인하여 둘다 새로 발급)
📝 case2 : access token은 만료됐지만, refresh token은 유효한 경우 → refresh token을 검증하여 access token 재발급
📝 case3 : access token은 유효하지만, refresh token은 만료된 경우 → access token을 검증하여 refresh token 재발급
📝 case4 : access token과 refresh token 모두가 유효한 경우 → 정상 처리
[refresh token을 검증하여 access token 재발급]
- 클라이언트(쿠키, 웹스토리지)에 저장되어있는 refresh token과 서버 DB에 저장되어있는 refresh token 일치성을 확인한 뒤 access token 재발급한다.
[access token을 검증하여 refresh token 재발급]
- access token이 유효하다라는 것은 이미 인증된 것과 마찬가지니 바로 refresh token 재발급한다.
3. 로그아웃 시 모두 만료시킨다.
🎢 과정
-
사용자가 ID , PW를 통해 로그인.
-
서버에서는 회원 DB에서 값을 비교
-
로그인이 완료되면 Access Token, Refresh Token을 발급한다. 이때 회원DB에도 Refresh Token을 저장해둔다.
-
사용자는 Refresh Token은 안전한 저장소에 저장 후, Access Token을 헤더에 실어 요청을 보낸다.
-
Access Token을 검증하여 이에 맞는 데이터를 보낸다.
-
시간이 지나 Access Token이 만료됐다.
-
사용자는 이전과 동일하게 Access Token을 헤더에 실어 요청을 보낸다.
-
서버는 Access Token이 만료됨을 확인하고 권한없음을 신호로 보낸다.
Tip
Access Token 만료가 될 때마다 계속 과정 7, 8을 거칠 필요는 없다.
사용자(프론트엔드)에서 Access Token의 Payload를 통해 유효기간을 알 수 있다.
따라서 프론트엔드 단에서 API 요청 전에 토큰이 만료됐다면 곧바로 재발급 요청을 할 수도 있다.
-
사용자는 Refresh Token과 Access Token을 함께 서버로 보낸다.
-
서버는 받은 Access Token이 조작되지 않았는지 확인한후, Refresh Token과 사용자의 DB에 저장되어 있던 Refresh Token을 비교한다. Token이 동일하고 유효기간도 지나지 않았다면 새로운 Access Token을 발급해준다.
-
서버는 새로운 Access Token을 헤더에 실어 다시 API 요청 응답을 진행한다.
참고자료
https://inpa.tistory.com/entry/WEB-📚-Access-Token-Refresh-Token-원리-feat-JWT [Inpa Dev 👨💻:티스토리]
