도입하게 된 계기

기존에 엔조이 트립에서는 access token과 refresh token이 존재하였다. refresh token 이용 부분의 개념이 약하기도 하기 때문에, 해당 부분을 리팩터링한 과정을 후술하도록 한다.

배운 점

• refresh token 은 jwt일 수도 있고, UUID일 수 도 있다.
  • JWT 일 경우, 서버의 부하가 적다. 디비 별도로 액세스 하지 않아도 된다. refresh token을 탈취당하면 토큰 무효화 시키는 방법 없다.
  • UUID 일 경우, 사용자 강제 로그아웃, 차단할 수 있게 된다. refresh token 탈취 되었을 때도, 즉시 무효화 시킬 수 있다.

메커니즘

• 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 모두가 유효한 경우 → 정상 처리

현재 스프링 구현 상태에서, header 로 부터 access token을 가져오고, 이는 유효성이 있을 때, 요청이 실행되는 구조이다.

<aside> 💡 case1일 때 → access token 만료된 에러가 뜬다 → /access-token 요청, refresh-token 만료되었다. → 에러

case2일 때 → access token 만료된 에러가 뜬다. → /access-token이 유효하다. refresh token 을 통해 access-token 재발급.

case3일 때, /refresh-token 요청 → refresh-token 재발급

case4일 때, 정상 동작.

</aside>

과 같이 구현 하면 된다.

우리 프로젝트에서는 refresh-token을 redis에 저장하였다. 왜냐하면, 인메모리 디비기 때문에 서버에 부담을 덜어줄 뿐만 아니라, TTL을 걸어주어, 만료가 되면 자동 삭제 하는 로직을 구현하기 위해서 이다. 또한 로그아웃이 될 때, accessToken 을 redis의 blackList로 등록하기 위해서 redis를 이용하였다.

→ 이를 통해 액세스 토큰 유효기간 만큼 redis에 등록해놓으면, 해당 토큰이 블랙 리스트이기 때문에 로그인 할 수 없다. 또한 유효기간 지나면 자동으로 삭제된다.