1. JWT의 보안
JWT의 단점에는 서버가 아닌 클라이언트에서 token을 관리하기 때문에, 세션과 달리 변조의 위협이 생겨도 서버에서 강제로 토큰을 삭제하지 못하는 점이 있다. 이와 같은 점을 보완하기 위해 일반적으로 만료시간과 Refresh token을 사용한다.
2. 만료시간
서버에서 토큰을 관리하지 못해 강제 제거가 안된다면 애초에 발급할 때부터 만료시간을 정해놓으면 된다. 발급시, 만료시간을 정해두고, 해당 시간이 지나면 토큰의 유효성을 잃게 되는 것이다. 또한 토큰 탈취시, 재사용을 막기 위해 사용하는 것이므로 만료 주기를 짧게 설정한다. (보통 2~30분 정도로 사용하는 것 같다)
하지만 여기서도 문제가 생긴다. 만료가 짧다면 해당 주기마다 사용자는 재로그인을 해야한다. 금융권이나 민감한 정보를 다루는 곳이라면 불편함을 안고서라도 보안성을 추구하겠지만, 일반적으로 짧은 주기마다 재로그인하는 프로세스를 사용자가 달가워할리 없다.
이를 해소하기 위해서는 토큰이 만료되었더라도 사용자의 특정 재로그인같은 조작없이 토큰을 갱신해줄 수 있는 방법이 필요하다. 이에 필요한 것이 Refresh token이다.
3. Refresh token
토큰을 발급할 때, Refresh token을 함께 발급해준다. Refresh token은 이름에서도 알 수 있듯이 만료된 토큰을 갱신해주는 토큰이다.
Refresh token은 갱신을 위한 토큰이기에 만료 주기를 보통 길게 잡아준다. (사용하는 사람마다 상이하다. 보통 2주 ~ 한달로 잡는 것 같다)
클라이언트는 Access Token이 만료되면 서버에 Refresh token과 함께 요청을 하여 Access Token을 갱신한다.
이와 같이 구성된다면 클라이언트의 재로그인없이 토큰을 갱신할 수 있게 된다. 다만 주의할 점은 Refresh token은 만료시간이 긴 토큰이기에 상대적으로 안전한 곳에 저장 해야한다.
4. 마치며
JWT를 이렇게 사용해야한다는 방식은 없다.
서버에서 만료시간을 알 수 있으므로 상위의 12번 같은 요청은 사실 서버에서 미리 처리하는 방법으로 구현할 수도 있고, Refresh token 저장 위치 또한 Local Storage, Cookie 혹은 서버 사이드 의견이 다양하다.
처리 방법에 대해서는 다양하게 구현하여 사용하지만 Access Token과 Refresh token을 사용한다는 큰 틀은 동일하기에 개념만 정리하였고, 각자 사용 용도에 맞게 구현하여 사용하면 되겠다.
참조
