JWT를 이용한 인증 처리 5. refresh 토큰 개념

이전 포스트에서 auth-token을 이용한 인증 처리에 대해서 살펴보았다. 이번 포스트에서는 refresh token이라는 개념에 대해서 살펴보자.

 

jwt auth token의 문제점과 보완

 

jwt auth token의 문제점

JWT는 세션을 사용할 수 없는 REST 환경에서 세션 처럼 인증 정보를 유지하기 위해서 사용된다. 세션의 경우는 사용자의 활동에 따라서 유효 기간이 연장되지만 토큰의 경우는 만들어진 시점에 이미 유통 기한이 정해져있다. 토큰은 유효기간이 자체적으로 연장되지는 않는다. 따라서 장기간 사용해야 하는 경우는 번거로움이 발생할 수 있다.

그럼 대안으로는 유효기간을 길~~게 가져갈 수 있다.  하지만 이때의 문제는 해커에 의한 토큰 탈취이다. 요청때마다 클라이언트에서 서버로 전송되는 이 토큰은 인증 정보를 가지고 있어서 일단 탈취되면 남은 유효기간 동안은 어쩔 수 없이 전권이 해커의 손아귀에 넘어가게 된다. 따라서 auth token의 유효기간을 길지 않게(30분~1시간?) 가져가는 것을 권장한다.

대신 상대적으로 긴 유효기간(2주?)을 가지는 refresh token을 두어서 auth token의 단점을 보완하게 된다.

 

refresh token의 동작 방식

• 일단 로그인 상황에서 달라진 점은 기존의 auth token과 함께 refresh token을 생성한다는 점이다. refresh token은 auth token과 달리 토큰에 사용자를 특정할 수 있는 정보(email 등)를 저장하지 않는다. 단지 유효한 토큰인지만 확인하면 되고 따라서 탈취 되더라도 큰 부담이 없다. 따라서 auth thoken 대비 긴 유효기간을 갖는다. auth token 정보는 서버측에 저장되는 것이 없지만 refresh token은 서버에 사용자를 구분할 수 있는 정보와 함께 저장해둔다.
• 1시간이 경과 후 auth token의 유효기간이 만료된 토큰으로 서버에 정보를 요청하면 서버에서는 401 오류를 반환시킨다. 
• 401오류를 받은 클라이언트는 refresh token을 전달하면서 auth token 갱신을 요청하고 서버는 refresh token이 유효한지 확인 후 기존에 저장하고 있던 refresh token과 같다면 새로운 auth token을 발행해준다.
• 클라이언트는 새로운 auth token을 저장하고 이를 이용해서 서비스를 받게 된다.

 

클라이언트의 토큰 저장

여러가지 공격에 대해서 토큰을 보다 안전하게 관리하려면 클라이언트에서는 토큰을 어디에 저장하는 것이 좋을까? 이 포스트에서는 간단한 구현을 위해 session storage에 저장하고 있는데 이것 보다는 쿠키에 HttpOnly와 Secure를 활용하는 방식이 권장되고 또 이것보다는 refresh token을 DB에 저장하고 이를 나타내는 index를 저장하기도 한다.

JWT 혹은 OAuth2 의 refresh 토큰을 어디다 저장해야 할까? | 두글 블로그 (doogle.link)​

JWT 혹은 OAuth2 의 refresh 토큰을 어디다 저장해야 할까? | 두글 블로그

 

여기는 개념을 공부하는 블로그이니까 상세한 구현은 독자분들의 상황에 맞춰서 작성해보기 바란다.