Today I Learned ...
오늘은 리프레시 토큰을 생성하고, 리프레시 토큰을 기반으로 한 토큰 갱신 로직을 구현했다!
🖥️ 번쩍 팀프로젝트 #17
JWT는 토큰 안에 서비스에 접근할 수 있는 권한이 저장되어 있다.
이 토큰이 탈취될 경우, 이 토큰을 통해 모든 내용들에 접근할 수 있게 되어버린다.
그래서 토큰이 탈취되어도 큰 문제가 되지 않도록 하기 위해 토큰의 만료 시간을 짧게 설정하게 된다.
우리 서비스에서는 이 토큰의 만료 시간을 1시간으로 설정했는데, 이렇게 서비스를 운영하게 되면 사용자는 1시간마다 다시 로그인해서 토큰을 발급받아야만 한다.
하지만, 실제 서비스가 이렇게 운영된다면.. 내가 사용자라면 절대 사용하지 않을 것 같다..
그래서 이때 사용되는 것이 Refresh 토큰이라는 개념이다.
리프레시 토큰은 토큰을 재발급 하기 위한 토큰으로, 서비스에 접근할 때 사용하는 Access 토큰보다 유효 시간이 길다는 특징이 있다.
사용자가 최초 로그인을 할 때 액세스 토큰과 리프레시 토큰을 모두 발급하고, 리프레시 토큰에 대해서는 서버 혹은 DB를 통해 저장해둔다.
만약 사용자의 액세스 토큰이 만료된다면, 사용자는 리프레시 토큰을 통해서 서버에 액세스 토큰 재발급을 요청하게 되고,
서버는 사용자가 보낸 리프레시 토큰과 서버에 저장되어 있는 리프레시 토큰을 확인하고, 리프레시 토큰의 유효 기간 등을 확인한 뒤, 유효하다면 액세스 토큰을 재발급 해준다.
사실 백엔드 입장에서 생각한다면 결국 로그인을 다시 하는 것과 다를 바가 없지만,
실제 사용자가 사용할 때는 프론트엔드에서 저 작업을 알아서 진행해주게 된다.
처음 요청했을 때 토큰으로 인한 에러가 생기면, 리프레시 토큰을 통해 액세스 토큰 재발급을 요청하고, 발급받은 액세스 토큰으로 다시 처음 요청을 시도하게 된다.
JWT를 통한 구현인지는 모르겠지만, 대부분의 서비스에서는 이 리프레시 토큰을 사용하고 있다.
그래서 로그인 상태 유지가 가능한 것이었다.
사실 나는 프론트엔드가 어떻게 동작하는지 몰라서 이 부분을 직접 실험해보지는 못하지만.. 그래도 성공적으로 리프레시 토큰 생성과 액세스 토큰 재발급을 진행할 수 있었다.
우리 팀이 작성한 코드는 깃허브를 통해 업로드해두었다.
GitHub 보러가기
🙃 오늘의 느낀점
V3가 되고 이런 저런 기능들을 추가하고 있는데, 이러니까 우리 서비스가 점점 그럴듯 해지고 있다!
실제로 운영되는 서비스들을 생각하면서 이런 기능도 추가해보고, 저런 기능도 추가해보고 있는데, 점점 그럴듯한 모양새를 갖추니 더 재미있어졌다.
내일은 유저 탈퇴 처리나 레디스 조회수 확인 등 기타 로직들을 조금만 더 수정해보고, 엘라스틱 서치 도입을 시작해보려고 한다.
앞으로도 화이팅!!
