Access와 Refresh Token

주특기 토이 프로젝트 이틀째다

FE와 BE 첫 협업으로 일주일이라는 시간 동안 하나의 프로젝트를 완성해야하다보니

걱정이 되었는데 BE 개발 스코프를 인원에 비해 작게 잡은 탓인지 생각보다 구현이 빨리 되었다.

물론 FE 구현이 완료되었을 때 함께 테스트를 해보면 어떤 에러들이 발생할지 모르겠지만....ㄷㄷ

아무튼 FE 작업 완료를 기다리는 언어 학습을 해볼까 하다가 프로젝트에 추가할 수 있는 기능이 없을까 고민하다가

주특기 학습 주차에 배웠던 access, refresh 토큰이 떠올랐다.

그때는 그냥 그런 것이 있구나 하고 훑고 지나갔는데 이번 기회에 다시 공부하여 프로젝트에 적용해보면 좋을 것 같다.

그래서 천천히 정리부터 시작해보겠다.

 

 

왜 토큰을 둘로 나누었나?

기존에 하나의 토큰을 사용한 인증 방식은 탈취 당할 경우 보안에 취약하다는 단점이 있다.

JWT는 발급한 후 삭제가 불가능하기 때문에 유효시간을 설정하여 보안을 강화했다.

그러나 유효시간이 만료되면 사용자는 로그인을 다시 해야하기 때문에 보안을 강화하기

위해 유효시간을 짧게 설정할 수록 사용자의 불편은 증가한다.

그래서 보안과 사용자의 편의를 모두 고려한 방법이 토큰을 두개로 나누어 각각 다른 역할을 부여하는 것이다.

형태 자체는 기존의 JWT와 동일하다. 단지 Access Token은 인증에 관여하고 Refresh Token은 재발급에 관여한다.

 

 

Access Token과 Refresh Token의 작동 원리

1. 사용자가 로그인을 하면 Access Token과 Refresh Token을 발급한다.
   여기서 Refresh Token은 서버에 저장하고 Access Token과 Refresh Token을 쿠키 또는 웹 스토리지에 저장한다.
   
   
2. 사용자가 인증이 필요한 API에 접근하면 가장 먼저 토큰을 검사한다.
   이때 토큰의 유효시간을 검증하여 재발급 여부를 결정한다.
   
   
3. 로그아웃을 하면 Access Token과 Refresh Token을 모두 만료시킨다.

 

결국 로그인할 때 같은 토큰을 두 개 발급하여

Refresh Token은 만료 시간을 상대적으로 길게 설정하여 (보통 1 - 2주) 서버에 저장하고

Access Token은 사용자의 정보를 담아 유효시간을 짧게 설정하여

사용자 인증이 필요한 API에 호출 할때마다 두개의 토큰을 모두 검사한다.

사용자의 정보를 담은 Access Token의 유효성을 검증하고 만료되었을 경우

Refresh Token을 이용해 Access Token을 재발급한다.

하지만 만약 Refresh Token도 만료가 되었다면 사용자는 다시 로그인을 해야한다.

이제 실제 코드에 적용해보고 시행착오를 겪어봐야겠다.