Refresh Token은 왜 필요할까?
이 글은 우아한테크코스 프론트엔드 6기 러기에 의해 작성되었습니다.
일반적으로 알고 있는 Refresh Token의 역할을 되짚어보겠습니다. Access Token은 유효 기간이 있는 인증 토큰으로, 만료되면 더 이상 보호된 리소스에 접근할 수 없습니다. 이때 Refresh Token을 사용하여 새로운 Access Token을 요청할 수 있습니다. 새로운 Access Token을 받으면 이를 사용하여 원하는 리소스에 접근할 수 있습니다.
그렇다면, “Refresh Token만 가지고 있으면, Access Token을 발급받아, 원하는 리소스를 얻을 수 있는 것 아닌가?” 라는 생각이 들 수 있습니다. 이 질문은 특히 Access Token과 Refresh Token의 차이점을 명확히 이해하지 못했기 때문에 이런 질문이 나왔다고 생각합니다. .그렇다면 Access Token과 Refresh Token의 차이는 무엇일까요? 이러한 질문에 답하기 위해서는 OAuth 2.0 프레임워크에 대해 조금 더 깊이 이해할 필요가 있습니다.
OAuth 2.0의 구조에서 Access Token 과 Refresh Token
OAuth 2.0 프레임워크는 인증과 권한 부여를 위한 표준 프로토콜을 정의합니다. 이를 통해 클라이언트 애플리케이션은 리소스 서버에서 보호된 리소스에 접근할 수 있게 됩니다. 여기서 중요한 요소는 Access Token과 Refresh Token입니다.
https://datatracker.ietf.org/doc/html/rfc6749#section-1.5
RFC 6749에서 정의된 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 +---------------+
이 그림을 통해 OAuth 2.0의 주요 흐름을 이해할 수 있습니다. 클라이언트는 Authorization Server로부터 Access Token과 Refresh Token을 받습니다. Access Token은 Resource Server에 접근할 때 사용되며, 만료되면 Refresh Token을 사용해 새로운 Access Token을 받아올 수 있습니다.
Access Token에 대해 알아보자
Access Token은 리소스 서버에 보호된 리소스를 요청할 수 있도록 해주는 인증 수단입니다. RFC 6749에서는 Access Token에 대해 다음과 같이 설명합니다:
Access token credentials (as well as any confidential access token
attributes) MUST be kept confidential in transit and storage, and
only shared among the authorization server, the resource servers the
access token is valid for, and the client to whom the access token is
issued. Access token credentials MUST only be transmitted using TLS
as described in Section 1.6 with server authentication as defined by
[RFC2818].
When using the implicit grant type, the access token is transmitted
in the URI fragment, which can expose it to unauthorized parties.
The authorization server MUST ensure that access tokens cannot be
generated, modified, or guessed to produce valid access tokens by
unauthorized parties.
The client SHOULD request access tokens with the minimal scope
necessary. The authorization server SHOULD take the client identity
into account when choosing how to honor the requested scope and MAY
issue an access token with less rights than requested.
This specification does not provide any methods for the resource
server to ensure that an access token presented to it by a given
client was issued to that client by the authorization server.
직역하면 다음과 같습니다.
access token 자격 증명(및 기밀 access token 속성)은 전송 및 저장 시 기밀로 유지되어야 하며, 발급된 클라이언트, access token이 유효한 resource server들, 그리고 authorization server 간에만 공유되어야 한다. access token 자격 증명은 반드시 [RFC2818]에 정의된 서버 인증과 함께 섹션 1.6에서 설명된 대로 TLS를 사용해 전송되어야 한다.
암시적 승인 유형(implicit grant type)을 사용할 때, access token은 URI 조각(fragment)에 전송되며, 이로 인해 무단 사용자에게 노출될 수 있다.
authorization server는 무단 사용자가 유효한 access token을 생성, 수정, 또는 추측할 수 없도록 보장해야 한다.
클라이언트는 필요한 최소한의 범위(scope)로 access token을 요청해야 한다. authorization server는 요청된 범위를 어떻게 처리할지 결정할 때 클라이언트의 신원을 고려해야 하며, 요청된 것보다 권한이 적은 access token을 발급할 수 있다.
이 사양은 리소스 서버가 특정 클라이언트에 의해 제시된 access token이 인증 서버에 의해 해당 클라이언트에게 발급되었음을 보장할 수 있는 방법을 제공하지 않는다.
위 내용에서 access token은 resource server 그리고 authorization server 두 군데 모두 공유되는 토큰이라는 것을 알 수 있습니다.
Refresh Token에 대해 알아보자.
Refresh Token은 Access Token이 만료된 후 새로운 Access Token을 발급받기 위해 사용됩니다. Refresh Token은 더 긴 수명을 가지며, Authorization Server와 클라이언트 간에만 공유됩니다. RFC 6749에서는 Refresh Token에 대해 다음과 같이 설명합니다:
Authorization servers MAY issue refresh tokens to web application
clients and native application clients.
Refresh tokens MUST be kept confidential in transit and storage, and
shared only among the authorization server and the client to whom the
refresh tokens were issued. The authorization server MUST maintain
the binding between a refresh token and the client to whom it was
issued. Refresh tokens MUST only be transmitted using TLS as
described in Section 1.6 with server authentication as defined by
[RFC2818].
The authorization server MUST verify the binding between the refresh
token and client identity whenever the client identity can be
authenticated. When client authentication is not possible, the
authorization server SHOULD deploy other means to detect refresh
token abuse.
For example, the authorization server could employ refresh token
rotation in which a new refresh token is issued with every access
token refresh response. The previous refresh token is invalidated
직역하면 다음과 같습니다.
authorization server는 웹 애플리케이션 클라이언트와 네이티브 애플리케이션 클라이언트에게 refresh token을 발급할 수 있다.
refresh token은 전송 및 저장 시 기밀로 유지되어야 하며, 발급된 클라이언트와 authorization server 간에만 공유되어야 한다. authorization server는 refresh token과 발급된 클라이언트 간의 연관성을 유지해야 한다. refresh token은 반드시 섹션 1.6에서 설명된 대로 TLS를 사용해 전송되어야 하며, [RFC2818]에 정의된 서버 인증이 포함되어야 한다.
authorization server는 클라이언트의 신원을 인증할 수 있는 경우마다 refresh token과 클라이언트 신원 간의 연관성을 확인해야 한다. 클라이언트 인증이 불가능한 경우, authorization server는 refresh token의 남용을 탐지하기 위한 다른 수단을 배포해야 한다.
예를 들어, authorization server는 매 액세스 토큰 갱신 응답 시 새로운 refresh token을 발급하는 refresh token 회전을 사용할 수 있다. 이전 refresh token은 무효화되지만 authorization server에 의해 유지된다. Refresh token이 손상되고 이후 공격자와 합법적인 클라이언트가 모두 이를 사용하게 되면, 둘 중 하나는 무효화된 refresh token을 제시하게 되어, authorization server에 침해 사실을 알리게 된다.
authorization server는 무단 사용자가 유효한 refresh token을 생성, 수정, 또는 추측할 수 없도록 보장해야 한다.
이 내용에서 refresh token이 authorization server와 클라이언트 간에만 사용되며, 이 연관성은 Authorization Server에 의해 유지되어야 한다는 점을 알 수 있습니다.
즉 access token과 refresh token은 다릅니다.
Access Token과 Refresh Token의 차이점을 요약해보자.
- Refresh Token은 Authorization Server에서 Access Token을 받을 수 있는 요청 권한을 부여합니다. 이로 인해 Refresh Token을 탈취하더라도 직접적으로 Resource Server에 접근할 수 없습니다.
- Access Token은 Resource Server에 보호된 리소스에 접근할 수 있는 인증 수단입니다. Access Token이 만료되면 Refresh Token을 사용해 새로운 Access Token을 발급받아야 합니다.
- Refresh Token은 Authorization Server에 의해 관리되며, 비정상적인 접근에 대한 구분이 가능합니다. 예를 들어, Refresh Token Rotate(매번 새로운 Refresh Token 발급)과 같은 보안 메커니즘이 사용됩니다. 또한, IP 주소, 위치, 장치 정보, 사용자 행동 분석 등을 통해 비정상적인 요청을 감지할 수 있습니다.
결론
- authorization server에서 관리되는 것이 Refresh Token!
- authorization server는 Refresh Token을 가지고 있다고 해서, 무조껀 Access Token을 주는게 아니다.
- Refresh Token Rotate와 사용자 정보를 바탕으로 보안 장치를 만들어, Access Token만 사용할 때보다 안전한 인증 구조를 만들 수 있습니다!
Access Token과 Refresh Token은 함께 사용함으로써 인증 과정의 보안성과 유연성을 모두 강화할 수 있습니다. Refresh Token을 통해 Access Token의 수명을 연장하고, 이를 통해 사용자는 재로그인 없이 지속적으로 보호된 리소스에 접근할 수 있습니다. 이 모든 과정은 OAuth 2.0 프레임워크 내에서 안전하게 이루어지며, 더 나은 보안 체계를 구축할 수 있습니다.