Access Token + Refresh Token JWT 인증

Refresh token 사용 이유

• Access Token(JWT)를 통한 인증 방식의 문제

• 제 3자에게 탈취당할 경우 보안에 취약하다는 점입니다.

• 유효기간이 짧은 Token의 경우 그만큼 사용자는 로그인을 자주 해서 새롭게 Token을 발급받아야 하므로 불편합니다. ⇒ 유효기간을 늘리면, 토큰을 탈취당했을 때 보안에 더 취약해지게 됩니다.

• “유효기간을 짧게 하면서  좋은 방법이 있지는 않을까?”라는 질문의 답이 바로 "Refresh Token"입니다.

Refresh Token

• Access Token과 똑같은 형태의 JWT

• 로그인 시 Access Token과 동시에 발급되는 Refresh Token은 긴 유효기간을 가지면서, Access Token이 만료됐을 때 새로 발급해주는 열쇠가 된다.

ex. Refresh Token의 유효기간은 2주, Access Token의 유효기간은 1시간일때.

사용자는 API 요청을 신나게 하다가 1시간이 지나게 되면, 가지고 있는 Access Token은 만료됩니다.

그러면 Refresh Token의 유효기간 전까지는 Access Token을 새롭게 발급받을 수 있습니다.

• Access Token은 탈취당하면 정보가 유출되는건 동일합니다. 다만 짧은 유효기간 안에만 사용이 가능하기에 더 안전하다는 의미입니다.

• Refresh Token의 유효기간이 만료됐다면, 사용자는 새로 로그인해야 합니다.
  • Refresh Token도 탈취될 가능성이 있기 때문에 적절한 유효기간 설정이 필요. (보통 2주 - 1달)

인증 과정

1-2. 사용자가 ID , PW를 통해 로그인합니다.

3-4. 로그인이 완료되면 Access Token, Refresh Token을 발급합니다.

• 이때 일반적으로 회원DB에 Refresh Token을 저장해둡니다.

5-7. 사용자는 Refresh Token은 안전한 저장소에 저장 후, Access Token을 헤더에 실어 요청을 보냅니다. 서버는 Access Token을 검증하여 이에 맞는 데이터를 보냅니다.

8. 시간이 지나 Access Token이 만료되면

9. 사용자는 이전과 동일하게 Access Token을 헤더에 실어 요청을 보냅니다.

10-11. 서버는 Access Token이 만료됨을 확인하고 권한없음을 신호로 보냅니다.

• Access Token 만료가 될 때마다 계속 과정 9~11을 거칠 필요는 없습니다.

• 사용자(프론트엔드)에서 Access Token의 Payload를 통해 유효기간을 알 수 있습니다. 따라서 프론트엔드 단에서 API 요청 전에 토큰이 만료됐다면 바로 재발급 요청을 할 수도 있습니다.

12. 사용자는 Refresh Token과 Access Token을 함께 서버로 보냅니다.

13. 서버는 받은 Access Token이 조작되지 않았는지 확인한 후, Refresh Token과 사용자의 DB에 저장되어 있던 Refresh Token을 비교합니다. Token이 동일하고 유효기간도 지나지 않았다면 새로운 Access Token을 발급해줍니다.

14. 서버는 새로운 Access Token을 헤더에 실어 다시 API 요청을 진행합니다.

 

위 방식으로 보안상의 이점을 얻을 수 있습니다. access 토큰의 경우 로그가 그대로 노출되는 경우가 많은데, 이 토큰의 유효기간을 너무 길게하면 공격자가 이를 악용할 가능성이 커진다는 것입니다. 따라서 잘 api 요청 시 잘 노출되지 않는 refresh toke을 사용하면 보안적으로 좀 더 안전하다고 주장하는 것 같습니다.

하지만 여기에도 단점이 존재하는데, 서버에 accesstoke 만료 시 refresh 요청을 보내야 하므로 부하가 커진다는 것입니다. 이때 부하를 줄이기 위해, access token 의 expiredAt 같은 만료 시간을 같이 저장해 두었다가 만료시에만 다시 요청을 보내는 식으로 구현해야 합니다. 저도 처음 구현할 때 403 에러 날때에 refresh token 엔드포인트에 요청을 보내고 액세스 토큰을 받아온 뒤 새로고침 하게 구현했다가 실패한 요청 다시 쏘게 구현하고 있습니다. ㅎㅎ

참고 - 쉽게 알아보는 서버 인증 2편(Access Token + Refresh Token)