로그인은 정말 다양한 방법을 사용해서 구현할 수 있다. 나는 지금까지는 JWT 토큰을 session storage에 저장해서 로그인하는 방법을 주로 사용했는데 지난 토이 프로젝트에서는 refresh token을 통해 access token을 갱신하는 방법을 사용했다. 이번 포스팅에서는 refresh token을 사용해서 어떻게 access token을 갱신했는지에 대해 정리해보려고 한다.
Refresh token과 Access token
Access token의 문제점
먼저 왜 refresh token을 사용해야 하는지에 대해 알 필요가 있다.
우리 사이드 프로젝트의 access token의 지속시간은 1시간이었다. 즉 로그인 후 1시간이 지나면 자동으로 로그아웃이 되어 사용자 경험을 저해시키는 요인이 되었다.
그렇다면 access token 자체의 지속시간을 늘리면 어떻게 될까?
access token은 발급 이후 서버에 저장되지 않고 토큰의 유효성 검사를 통해 사용자 권한을 인증한다. 즉 access token을 가지고 있다면 누구나 만료 전까지 접근 권한을 가지게 된다는 의미이며 이러한 이유로 access token을 통한 인증방식은 access token이 제 3자에게 탈취당할 경우 보안에 취약하다는 문제를 가진다.
이러한 문제를 해결하기 위해 나온 방법이 refresh token이다.
Refresh token이란?
refresh token은 access token을 재발급받을 수 있는 token이다. refresh token은 access token과 달리 서버에 저장되므로 refresh token이 탈취당했다고 판단되면 서버에서 refresh token을 삭제함으로써 강제 로그아웃 시킬 수 있다. 때문에 access token과 refresh token을 함께 도입할 경우 access token의 경제적인 장점(stateless)과 refresh token의 보안적인 장점(stateful)을 모두 가져갈 수 있다.
즉 refresh token을 사용하면 access token의 유효시간을 짧게 가져가면서 사용자에게는 잦은 로그아웃을 경험하지 않도록 할 수 있다.
서비스 정책에 따라 다르지만 보통 access token은 1시간 정도의 짧은 시간의 지속시간을 가지며 refresh token은 일주일에서 한달까지 긴 지속시간을 가진다.
Refresh token의 인증과정을 그림으로 표현하면 아래와 같다.
구글에 검색해 본 결과 access token의 지속시간이 만료되었을 경우 request 요청 전에 access token이 만료되었는지 확인 후 refresh token을 활용해 access token을 재발급 받을 수도 있고 response로 invalid token error가 왔을 때 refresh token을 활용해 access token을 재발급 받을 수도 있는 것 같다.
프로젝트 적용 과정
위에서 알아본 이유들로 우리 프로젝트에서도 refresh token을 적용하기로 했다. 그렇다면 refresh token과 access token은 어디에 저장되어야 할까? 이 질문의 답을 찾기 위해 프론트엔드 개발자들끼리 많은 이야기를 나누었다. 서비스의 성격에 따라 다르고 정책에 따라 다를 것이기 때문에 정답은 없지만 우리 팀에서 결정한 내용은 아래와 같다.
먼저 우리 프로젝트는 Next.js로 되어 있어 SSR 요청을 할 경우 브라우저의 저장소에 접근하지 못했다. 때문에 SSR 요청시 ctx 객체에서 접근할 수 있는 cookie에 refresh token을 저장하기로 결정했다.
문제는 access token의 저장 위치였는데 우리는 payload에 유저 아이디와 같은 정보를 저장했으므로 브라우저 저장소에 access token을 저장하는 것은 보안상 좋지 않다고 생각했다. 이와 같은 이유로 access token은 axios header에 저장해두고 만료 시 refresh token을 통해 재발급 받도록 하기로 결정했다.
access token을 재발급 받는 과정은 axios interceptor를 사용해 서버의 response로 invalid token이라는 에러가 들어왔을 경우 refresh token을 사용해 access token을 재발급 받는 요청을 보내는 방식으로 구현했다.
우리가 선택한 방법은 access token을 브라우저 저장소에 저장하지 않아 보안상의 이점이 있었지만 axios header의 경우 페이지가 새로고침되면 refresh 되므로 access token 재발급 요청이 잦다는 단점이 있었다.
왠지 모르게 거의 모든 프로젝트에서 로그인 기능을 구현하고 있는 것 같은데 지금까지는 동일한 방식으로 구현하다 처음으로 refresh token을 활용해 access token을 갱신하는 방식을 구현해 보았다. 그냥 재발급 요청만 하면 될 줄 알았는데 생각보다 고려할 사항이 많았고 중요한 건 어떤 게 더 좋을지에 대해 고민하는 과정에서 시간이 많이 들었다. 이번에 고민한 내용을 바탕으로 해서 다음 프로젝트를 진행하게 되면 좀 더 발전된 방법으로 구현하고 싶다…!!!
