[Token] JWT Token Management

JWT 토큰 발급 후, 토큰 관리

JWT 토큰을 발급할 때, 만료기간을 주는데 한 번 발급한 토큰은 만료될 때까지 변경할 수 없다.
Access Token과 Refresh Token이 있는데, 말그대로 Access Token은 접속에 관여하는 토큰이고, Refresh Token은 재발급에 관여하는 토큰이다.
JWT는 발급한 후, 삭제가 불가능하기 때문에 접근에 관여하는 토큰은 유효시간을 길게 부여할 수 없는데, 자동 로그인 또는 로그인 유지를 위해서는 토큰의 유지가 필요하다. 이때, 사용하는 token이 refresh token이다.
access token의 재발급 방법으로는

• 요청마다 access token과 refresh token을 같이 reponse
• 재발급 token api를 만들고 서버에서 access token의 만료를 확인 하고, 확인이되면, refresh token을 response
  access_token의 경우 유효주기를 짧게 가져가는 이유는 보안상의 이슈 때문이다. 만약, 유효주기 내에 token string을 탈취당하여, 접근 권한을 탈취당하면 보안적인 이슈가 생기기 때문이다.
  refresh token은 access token보다 유효 주기가 길게 발급이된다. 대신, refresh token에는 access token과 같이 접근 권한과 같은 정보가 담기는 것이 아니라 access token을 재발급 하는 정보만을 가지게 된다.

그렇다면 어떻게 refresh token이 access token을 재발급하게 되는걸까??
보통 Refresh Token은 로그인 성공시 발급이되며, 데이터베이스에 저장되고 관리된다.
그리고 로그아웃을 하면 저장소에서 Refresh token을 삭제하여, 사용이 불가능하도록 만든다.

• refresh_token을 access_token처럼 HTTP 헤더의 Authorization속성으로 전달 받는다.
• 토큰의 payload의 type을 통해 ATK OR RTK를 구분한다.(access_token인지 refresh_token인지!!)
• RTK이고, URI가 access_token을 재발급하는 api route인 경우 재발급을 진행한다.
• access_token 재발급은 refresh_token의 payload에서 유저의 email을 꺼낸 뒤, Redis 인메모리에 해당 유저의 존재 유무로 결정된다.
• tokenresponse에 새로운 access_token을 넣어 response한다.
• 클라이언트는 재발급된 access_token을 request header에 심어 request하면 정상적인 인증 절차를 가진다.
• type이 다른 token은 다른 URI에 접근을 할 수 없기 때문에, jwt의 type필드의 정의는 중요하다.

이미 사용한 access_token에 대해서 데이터베이스에 blacklist라는 column을 이용하여 관리를 할 수 있다. 로그아웃이 진행되면, blacklist에 해당 유저의 token값을 저장하고, 나중에 해당 토큰으로 access request가 들어오게 되면, 권한을 부여하지않고 로그인 페이지로 redirect 시켜버리면 된다. 이때, 저장소 역할로 redis를 많이 사용하곤 한다.

참조

https://sol-devlog.tistory.com/22