Refresh Token이란?

이전글에서 Jwt가 무엇인지, Jwt를 Access Token으로 사용했을 때 문제점이 무엇인지 정리했다.

 

다시 토큰 기반 인증에서 Access Token의 문제점이 무엇이었는지 간단히 정리하겠다.

 

Access Token의 문제점

• Access Token은 서버에서 발급하고 나면 관리할 수가 없다. 만료일을 정해놓고 보내면 끝이며 만료일이 지나면 새로 발급받아야 한다.
• 서버가 토큰을 보관하고 있지 않기 때문에 한번 발급된 토큰이 탈취되면 그에 대한 제어를 할 수가 없다.
  • 탈취당한다면 그 사용자의 계정은 다 털리게 되며, 만료일이 지날 때까지 어떻게 처리해줄 수가 없다.

탈취당했을 경우를 생각하여 어떻게 제어를 해야 할 지에 대한 보완 방법으로 나타난 게 Refresh Token이다.

탈취당한 토큰을 서버에서 제어할 수 없으니 유효 기간을 짧게하고 계속 재발급하겠다는 방안이다.

이전에 작성했듯이 완벽한 인증 방법은 없다.. 계속 취약점을 보완해 나가는 것이다.

 

Refresh Token이란?

• Refresh Token은 Access Token의 유효 기간을 짧고, 자주 재발급 하도록 만들어 보안을 강화하면서도 사용자에게 잦은 재발급으로 인한 재 로그인을 하지 않게 하도록 하는 것이다.
• Access Token은 리소스에 접근하기 위한 토큰이라면, Refresh Token은 사용자가 가지고 있던 Access Token이 만료되었을 때 새로 발급받기 위해 사용한다.
  • Access Token의 유효 기간을 짧게 5~10분 정도로 설정하고 계속 재발급시킨다.
• Oauth 2.0에서 사용되는 방식을 예로 본다.

// Oauth 2.0
  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

// 출처: https://www.rfc-editor.org/rfc/rfc6749.html

1. 클라이언트가 로그인과 같은 인증 절차를 거침
2. 인증 서버에서 Access Token과 Refresh Token을 발급(Refresh Token은 DB에 저장)
3. 클라이언트는 Access Token을 Header에 담아서 Resource Server에 요청하고 토큰 검증을 통해 응답
4. 만료된 Access Token에 대해서는 Error로 응답
5. Access Token이 만료되면 Refresh Token을 인증 서버에 보내고 새로운 Access Token을 받는다. Refresh Token 만료시간에 따라 Refresh도 재발급받는다.

Access Token이 만료될 때마다 계속 Error 응답 후 인증 서버로 요청할 필요는 없다.
API 호출 전에 Payload에 담긴 만료시간을 확인한 후 Refresh 하고 Resource Server로 보내어 관리할 수 도 있다.

 

Refresh Token의 한계

• Access token의 유효기간을 짧게 설정한다고 해도 탈취당한 즉시 제어할 순 없다.
• Refresh Token을 탈취당하면 이전과 똑같은 문제가 발생한다. Refresh Token이 탈취 여부를 알 수 없다.

Refresh Token을 사용하면 Access Token만 사용할 때보다는 보안이 강화되었다고 생각되지만 여전히 문제점은 남아있다. 탈취당하지 않도록 클라이언트는 XSS, CSRF 공격으로부터 안전하게 보관을 해야 하며 서버는 DB의 Refresh Token이 탈취되면 안 된다.(사실 서버 DB가 털리는 게 말이...) 이에 대해 새로운 방안으로 RTR(Refresh Token Rotation)이라는 것이 있다.

 

RTR(Refresh Token Rotation)

• Refresh Token을 사용하여 새로운 Access Token을 발급받을 때 Refresh Token도 재발급을 하는 것
• Refresh Token은 Access Token 재발급 시 딱 1회 사용되며 Refresh Token도 재발급되는 것
• 이미 사용했던 Refresh Token이 다시 사용되면 서버 측에서 탈취 여부를 확인할 수 있음
  • Access Token만 탈취해서 사용한다면 탈취여부를 알 수 없음 하지만 이전보다 더 안전할 것이다.

 

'완벽한 인증 방법이란 없다'라는 말이 왜 있는지 깨닫게 됐다.. 또 요즘 컴퓨터 보안 수업을 듣고 있는데 어떤 보안이든 언젠가는 뚫릴 수 있으며 기업이나 정부에서 정기적으로 보안 이슈를 다루고 고민하는 이유를 알려주셨던 기억이 난다..

최근에 본 유튜브는 요즘 재택근무가 많이 늘어나고 있음에 따라 원격 관리에 대한 보안 이슈가 가장 큰 이슈라고 얘기해줬던 게 생각난다.. 우린 항상 보안을 신경 써야 하고 취약점에 대한 컨설팅을 받아야 한다...

 

어떤 서비스를 제공하고 어떻게 구축하느냐에 따라 인증방식도 우리 서비스에 맞춰 구현해야 할 것 같다!! 정답은 없는 듯하다..