OAuth 2.1 권한 부여 프레임워크

1.3.1. 권한 부여 코드

권한 부여 코드는 접근 토큰을 얻는 데 사용되는 임시 자격 증명이다. 클라이언트가 리소스 소유자에게 직접 권한 부여를 요청하는 대신, 클라이언트는 리소스 소유자를 (사용자 에이전트를 통해) 권한 부여 서버로 안내하고, 권한 부여 서버는 다시 리소스 소유자를 권한 부여 코드와 함께 클라이언트로 되돌려 보낸다. 그러면 클라이언트는 권한 부여 코드를 접근 토큰으로 교환할 수 있다.¶

권한 부여 서버는 권한 부여 코드와 함께 리소스 소유자를 클라이언트로 되돌려 보내기 전에 리소스 소유자를 인증하고, 리소스 소유자의 동의를 요청하거나 클라이언트의 요청을 알릴 수 있다. 리소스 소유자는 권한 부여 서버에서만 인증하므로, 리소스 소유자의 자격 증명은 클라이언트와 공유되지 않으며, 클라이언트는 다중 인증이나 위임 계정 같은 추가 인증 단계에 대해 알 필요가 없다.¶

권한 부여 코드는 클라이언트를 인증할 수 있는 능력, 접근 토큰을 리소스 소유자의 사용자 에이전트를 통과시키지 않고 클라이언트로 직접 전송하여 리소스 소유자를 포함한 타인에게 노출될 가능성을 줄이는 것 같은 몇 가지 중요한 보안 이점을 제공한다.¶

1.3.2. 갱신 토큰

갱신 토큰은 접근 토큰을 얻는 데 사용되는 자격 증명이다. 갱신 토큰은 권한 부여 서버가 클라이언트에 발급할 수 있으며, 현재 접근 토큰이 무효가 되거나 만료될 때 새 접근 토큰을 얻거나, 동일하거나 더 좁은 범위의 추가 접근 토큰을 얻는 데 사용된다 (접근 토큰은 리소스 소유자가 권한 부여한 것보다 더 짧은 수명과 더 적은 권한을 가질 수 있다). 갱신 토큰 발급은 권한 부여 서버의 재량에 따른 선택 사항이며, 클라이언트의 속성, 요청의 속성, 권한 부여 서버 내 정책 또는 기타 기준에 따라 발급될 수 있다. 권한 부여 서버가 갱신 토큰을 발급하는 경우, 접근 토큰을 발급할 때 포함된다(즉, 그림 2의 단계 (2)). 갱신 토큰의 수명 역시 권한 부여 서버의 재량에 따른다.¶

갱신 토큰은 리소스 소유자가 클라이언트에 부여한 권한 부여를 나타내는 문자열이다. 이 문자열은 클라이언트에 대해 불투명한 것으로 간주된다. 갱신 토큰은 권한 부여 정보를 검색하는 데 사용되는 식별자일 수 있고, 이 정보를 문자열 자체에 인코딩할 수도 있다. 접근 토큰과 달리, 갱신 토큰은 권한 부여 서버에서만 사용되도록 의도되며 리소스 서버로 전송되지 않는다.¶

+--------+                                           +---------------+
|        |--(1)------- Authorization Grant --------->|               |
|        |                                           |               |
|        |<-(2)----------- Access Token -------------|               |
|        |               & Refresh Token             |               |
|        |                                           |               |
|        |                            +----------+   |               |
|        |--(3)---- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<-(4)- Protected Resource --| Resource |   | Authorization |
| Client |                            |  Server  |   |     Server    |
|        |--(5)---- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<-(6)- Invalid Token Error -|          |   |               |
|        |                            +----------+   |               |
|        |                                           |               |
|        |--(7)----------- Refresh Token ----------->|               |
|        |                                           |               |
|        |<-(8)----------- Access Token -------------|               |
+--------+           & Optional Refresh Token        +---------------+

그림 2에 표시된 흐름은 다음 단계를 포함한다:¶

1. 클라이언트는 권한 부여 서버에 인증하고 권한 부여 그랜트를 제시하여 접근 토큰을 요청한다.¶

2. 권한 부여 서버는 클라이언트를 인증하고 권한 부여 그랜트를 검증하며, 유효한 경우 접근 토큰과 선택적으로 갱신 토큰을 발급한다.¶

3. 클라이언트는 접근 토큰을 제시하여 리소스 서버에 보호된 리소스 요청을 한다.¶

4. 리소스 서버는 접근 토큰을 검증하고, 유효한 경우 요청을 처리한다.¶

5. 단계 (3)과 (4)는 접근 토큰이 만료될 때까지 반복된다. 클라이언트가 접근 토큰이 만료된 것을 알고 있다면 단계 (7)로 건너뛰고, 그렇지 않으면 또 다른 보호된 리소스 요청을 한다.¶

6. 접근 토큰이 유효하지 않으므로, 리소스 서버는 유효하지 않은 토큰 오류를 반환한다.¶

7. 클라이언트는 갱신 토큰을 제시하고, 자격 증명이 발급된 경우 클라이언트 인증을 제공하여 새 접근 토큰을 요청한다. 클라이언트 인증 요구사항은 클라이언트 유형과 권한 부여 서버 정책에 따라 달라진다.¶

8. 권한 부여 서버는 클라이언트를 인증하고 갱신 토큰을 검증하며, 유효한 경우 새 접근 토큰(그리고 선택적으로 새 갱신 토큰)을 발급한다.¶

클라이언트가 수명 정보를 가지고도 달리 할 수 있는 일이 없으므로 갱신 토큰의 수명을 클라이언트에 전달할 필요는 없다. 또한 권한 부여 서버는 동적 수명(예: 갱신 토큰이 적어도 7일에 한 번 사용되는 한 갱신 토큰 만료가 연장됨)을 사용할 수 있으며, 사용자가 애플리케이션의 접근을 취소하는 경우처럼 어떤 이유로든 예정된 만료일 전에 갱신 토큰을 취소할 수 있다. 이는 클라이언트가 이미 갱신 토큰이 임의의 시점에 만료되는 경우를 처리해야 함을 의미한다.¶

갱신 토큰이 왜 또는 언제 만료되든, 클라이언트가 새 토큰을 얻는 유일한 경로는 처음부터 새 OAuth 흐름을 시작하는 것이다. 이러한 이유로 갱신 토큰의 만료를 클라이언트에 전달하는 속성은 정의되어 있지 않다.¶

1.3.3. 클라이언트 자격 증명

클라이언트 자격 증명 또는 다른 형태의 클라이언트 인증 (예: [RFC7523] 및 그 갱신판 [I-D.ietf-oauth-rfc7523bis]에 설명된 것처럼 JWT에 서명하는 데 사용되는 개인 키)은 권한 부여 범위가 클라이언트가 제어하는 보호된 리소스 또는 권한 부여 서버와 사전에 조정된 보호된 리소스로 제한될 때 권한 부여 그랜트로 사용할 수 있다. 클라이언트 자격 증명은 클라이언트가 권한 부여 서버와 사전에 조정된 권한 부여를 기반으로 보호된 리소스에 대한 접근을 요청할 때 사용된다.¶

1.4.1. 접근 토큰 범위

접근 토큰은 접근을 부여하는 사용자가 가진 권한보다 더 적은 권한으로 클라이언트에 발급되도록 의도된다. 이는 제한된 "scope" 접근 토큰으로 알려져 있다. 권한 부여 서버와 리소스 서버는 이 범위 메커니즘을 사용하여 특정 클라이언트가 가질 수 있는 리소스 유형이나 접근 수준을 제한할 수 있다.¶

예를 들어, 클라이언트는 사용자의 리소스에 대해 "read" 접근만 필요하고 리소스를 갱신할 필요는 없을 수 있다. 따라서 클라이언트는 권한 부여 서버가 정의한 읽기 전용 범위를 요청하고, 리소스 갱신에 사용할 수 없는 접근 토큰을 얻을 수 있다. 이는 권한 부여 서버, 리소스 서버, 클라이언트 간의 조율을 필요로 한다. 권한 부여 서버는 클라이언트가 특정 범위를 요청할 수 있는 기능을 제공하고, 클라이언트에 발급된 접근 토큰에 해당 범위를 연결한다. 그런 다음 리소스 서버는 제한된 범위의 접근 토큰이 제시될 때 범위를 집행할 책임이 있다.¶

OAuth는 어떤 범위 값도 정의하지 않는다. 대신 범위는 권한 부여 서버 또는 OAuth의 확장이나 프로파일이 정의한다. 범위를 정의하는 이러한 확장 중 하나가 [OpenID.Connect]이며, 이는 사용자의 프로파일 정보에 대한 세분화된 접근을 제공하는 범위 집합을 정의한다. 알려진 확장의 범위와 충돌하는 사용자 지정 범위를 정의하는 것은 피하는 것이 권장된다.¶

제한된 범위의 접근 토큰을 요청하기 위해, 클라이언트는 사용된 그랜트 유형에 따라 권한 부여 또는 토큰 엔드포인트에서 scope 요청 매개변수를 사용한다. 이에 따라 권한 부여 서버는 발급된 접근 토큰의 범위를 클라이언트에 알리기 위해 scope 응답 매개변수를 사용한다.¶

scope 매개변수의 값은 공백으로 구분된 대소문자 구분 문자열 목록으로 표현된다. 문자열은 권한 부여 서버가 정의한다. 값에 여러 공백 구분 문자열이 포함되는 경우 그 순서는 중요하지 않으며, 각 문자열은 요청된 범위에 추가 접근 범위를 더한다.¶

    scope       = scope-token *( SP scope-token )
    scope-token = 1*( %x21 / %x23-5B / %x5D-7E )

권한 부여 서버는 권한 부여 서버 정책 또는 리소스 소유자의 지시에 따라 클라이언트가 요청한 범위를 전부 또는 일부 무시할 수 있다. 발급된 접근 토큰 범위가 클라이언트가 요청한 범위와 다른 경우, 권한 부여 서버는 클라이언트에 실제 부여된 범위를 알리기 위해 토큰 응답 (Section 3.2.3)에 scope 응답 매개변수를 포함해야 한다.¶

클라이언트가 권한 부여를 요청할 때 scope 매개변수를 생략하면, 권한 부여 서버는 사전 정의된 기본값을 사용하여 요청을 처리하거나 유효하지 않은 범위를 나타내며 요청을 실패시켜야 한다. 권한 부여 서버는 자신의 범위 요구사항과 기본값(정의된 경우)을 문서화해야 한다.¶

1.4.2. Bearer 토큰

Bearer 토큰은 토큰을 소지한 어떤 당사자("bearer")든 그 토큰을 소지한 다른 당사자가 사용할 수 있는 방식으로 토큰을 사용할 수 있다는 속성을 가진 보안 토큰이다. Bearer 토큰 사용은 bearer가 암호학적 키 자료의 소유 (소유 증명)를 증명할 것을 요구하지 않는다.¶

Bearer 토큰은 DPoP [RFC9449] 및 mTLS [RFC8705] 같은 소유 증명 명세로 강화되어 소유 증명 특성을 제공할 수 있다.¶

접근 토큰 공개로부터 보호하기 위해, 클라이언트와 리소스 서버 간의 통신 상호작용은 Section 1.5에 설명된 기밀성 및 무결성 보호를 사용해야 한다.¶

bearer 토큰의 특정 구조나 형식에 대한 요구사항은 없다. bearer 토큰이 권한 부여 정보에 대한 참조인 경우, 그러한 참조는 충분히 긴 암호학적 난수 문자열을 사용하는 것처럼 공격자가 추측하기 불가능해야 한다. bearer 토큰이 토큰 자체에 권한 부여 정보를 포함하는 인코딩 메커니즘을 사용하는 경우, 접근 토큰은 토큰이 수정되는 것을 방지하기에 충분한 무결성 보호를 사용해야 한다. 접근 토큰의 인코딩 및 서명 메커니즘의 한 예는 접근 토큰용 JSON Web Token 프로파일 [RFC9068]에 설명되어 있다.¶

1.4.3. 발신자 제한 접근 토큰

발신자 제한 접근 토큰은 접근 토큰의 사용을 특정 발신자에게 바인딩한다. 이 발신자는 수신자(예: 리소스 서버)에서 해당 접근 토큰이 수락되기 위한 전제 조건으로 특정 비밀을 알고 있음을 입증해야 한다.¶

권한 부여 서버와 리소스 서버는 OAuth Demonstration of Proof of Possession (DPoP) [RFC9449] 또는 OAuth 2.0용 상호 TLS [RFC8705] 같은 발신자 제한 접근 토큰 메커니즘을 사용해야 한다. 도난 및 유출된 접근 토큰의 오용을 방지하려면 [RFC9700]의 Section 4.10.1을 참조한다.¶

클라이언트와 리소스 서버 간에 종단 간 TLS를 사용하는 것이 권장된다. TLS 트래픽을 중개자에서 종료해야 하는 경우, 추가 보안 조언은 [RFC9700]의 Section 4.13을 참조한다.¶

2.3.1. 등록 요구사항

권한 부여 서버는 클라이언트가 완전한 리디렉션 URI(경로 구성 요소 포함)를 등록하도록 요구해야 한다. 권한 부여 서버는 등록된 것과 정확히 일치하지 않는 리디렉션 URI를 지정하는 권한 부여 요청을 거부해야 하며, 루프백 리디렉션의 경우 포트 URI 구성 요소를 제외하고 정확한 일치가 요구되는 예외가 있다. 자세한 내용은 Section 4.1.1을 참조한다.¶

권한 부여 서버는 클라이언트가 여러 리디렉션 URI를 등록하도록 허용할 수 있다.¶

등록은 권한 부여 서버에서 클라이언트 정보를 구성하는 수동 단계처럼 대역 외에서 일어날 수도 있고, Pushed Authorization Requests [RFC9126]의 초기 POST처럼 런타임에 일어날 수도 있다.¶

사적 사용 URI 스킴 기반 리디렉션 URI의 경우, 권한 부여 서버는 클라이언트가 역 도메인 이름 기반 스킴을 사용해야 한다는 Section 8.4.3의 요구사항을 집행해야 한다. 최소한 마침표 문자(.)를 포함하지 않는 모든 사적 사용 URI 스킴은 거부되어야 한다.¶

충돌 방지 속성에 더하여, 이는 두 앱이 같은 사적 사용 URI 스킴을 주장하는 분쟁 상황에서 (한 앱이 악의적으로 동작하는 경우) 소유권을 입증하는 데 도움이 될 수 있다. 예를 들어 두 앱이 com.example.app을 주장했다면, example.com의 소유자는 앱 스토어 운영자에게 위조 앱 제거를 청원할 수 있다. 일반 URI 스킴을 사용했다면 이러한 청원은 입증하기 더 어렵다.¶

클라이언트는 쿼리 매개변수에서 얻은 임의 URI로 사용자의 브라우저를 전달하는 URL("open redirector")을 노출해서는 안 되며, 이는 Section 7.12에 설명되어 있다. 오픈 리디렉터는 권한 부여 코드와 접근 토큰의 유출을 가능하게 할 수 있다.¶

클라이언트는 필요하다면 요청별 맞춤화를 달성하기 위해 요청마다 리디렉션 URI를 변경하는 대신 state 요청 매개변수를 사용할 수 있다.¶

리디렉션 URI 등록을 요구하지 않으면, 공격자는 Section 7.12에 설명된 것처럼 권한 부여 엔드포인트를 오픈 리디렉터로 사용할 수 있다.¶

2.3.2. 여러 리디렉션 URI

클라이언트에 여러 리디렉션 URI가 등록되어 있다면, 클라이언트는 redirect_uri 요청 매개변수 (Section 4.1.1)를 사용하여 권한 부여 요청에 리디렉션 URI를 포함해야 한다. 클라이언트에 단일 리디렉션 URI만 등록되어 있다면, redirect_uri 요청 매개변수는 선택 사항이다.¶

2.3.3. CSRF 공격 방지

클라이언트는 Cross-Site Request Forgery (CSRF) 공격을 방지해야 한다. 이 맥락에서 CSRF는 권한 부여 서버에서 유래하지 않고 악의적인 제3자에서 유래하는 리디렉션 엔드포인트 요청을 의미한다 (자세한 내용은 [RFC6819]의 Section 4.4.1.8 참조). 권한 부여 서버가 code_challenge 매개변수를 지원함을 확인한 클라이언트는 이 메커니즘이 제공하는 CSRF 보호에 의존할 수 있다. OpenID Connect 흐름에서는 nonce 매개변수를 검증하는 것이 CSRF 보호를 제공한다. 그렇지 않으면 사용자 에이전트에 안전하게 바인딩된, state 매개변수에 담긴 일회용 CSRF 토큰을 CSRF 보호에 사용해야 한다 (Section 7.9 참조).¶

2.3.4. Mix-Up 공격 방지

OAuth 클라이언트가 하나의 권한 부여 서버와만 상호작용할 수 있는 경우, mix-up 방어는 필요하지 않다. 그러나 OAuth 클라이언트가 둘 이상의 권한 부여 서버와 상호작용하는 시나리오에서는 클라이언트가 mix-up 공격을 방지해야 한다. mix-up 공격을 방지하기 위해, 클라이언트는 해당 요청을 보낸 발급자와 동일한 사용자 에이전트에서 시작된 권한 부여 요청의 리디렉션 응답만 처리해야 한다.¶

mix-up 공격에 대한 두 가지 서로 다른 방어의 자세한 설명은 Section 7.14를 참조한다.¶

2.3.5. 유효하지 않은 엔드포인트

권한 부여 요청이 누락, 유효하지 않음 또는 불일치하는 리디렉션 URI로 인해 검증에 실패하는 경우, 권한 부여 서버는 리소스 소유자에게 오류를 알려야 하며, 사용자 에이전트를 유효하지 않은 리디렉션 URI로 자동 리디렉션해서는 안 된다.¶

2.3.6. 엔드포인트 콘텐츠

클라이언트 엔드포인트로의 리디렉션 요청은 일반적으로 사용자 에이전트가 처리하는 HTML 문서 응답으로 이어진다. HTML 응답이 리디렉션 요청의 결과로 직접 제공되는 경우, HTML 문서에 포함된 모든 스크립트는 리디렉션 URI와 그 안에 포함된 산출물(예: 권한 부여 코드)에 대한 전체 접근 권한으로 실행된다. 또한 권한 부여 코드가 포함된 요청 URL이 페이지에 로드된 내장 이미지, 스타일시트 및 기타 요소로 HTTP Referer 헤더를 통해 전송될 수 있다.¶

클라이언트는 리디렉션 URI 엔드포인트 응답에 제3자 스크립트(예: 제3자 분석, 소셜 플러그인, 광고 네트워크)를 포함해서는 안 된다. 대신 URI에서 산출물을 추출하고, 산출물을 (URI나 다른 곳에) 노출하지 않는 다른 엔드포인트로 사용자 에이전트를 다시 리디렉션해야 한다. 제3자 스크립트가 포함되는 경우, 클라이언트는 자체 스크립트(URI에서 자격 증명을 추출하고 제거하는 데 사용됨)가 먼저 실행되도록 보장해야 한다.¶

2.4.1. 클라이언트 시크릿

클라이언트 시크릿을 보유한 기밀 클라이언트를 지원하기 위해, 권한 부여 서버는 클라이언트가 다음 매개변수를 사용하여 요청 본문 콘텐츠에 클라이언트 자격 증명을 포함하는 것을 지원해야 한다:¶

"client_id":

REQUIRED. Section 2.2에 설명된 등록 과정 중 클라이언트에 발급된 클라이언트 식별자.¶

"client_secret":

REQUIRED. 클라이언트 시크릿.¶

매개변수는 요청 콘텐츠에서만 전송될 수 있으며 요청 URI에 포함되어서는 안 된다.¶

이는 [RFC7591]의 Section 2에 정의된 client_secret_post로도 알려져 있다.¶

예를 들어, 콘텐츠 매개변수를 사용하여 접근 토큰을 갱신하는 요청 (Section 4.3) (표시 목적의 추가 줄바꿈 포함):¶

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

권한 부여 서버는 클라이언트 시크릿을 발급받은 클라이언트를 인증하기 위해 HTTP Basic 인증 스킴을 지원할 수 있다.¶

권한 부여 서버에 인증하기 위해 [RFC9110]의 Section 11에 정의된 HTTP Basic 인증 스킴을 사용할 때, 클라이언트 식별자는 Appendix B에 따라 application/x-www-form-urlencoded 인코딩 알고리즘을 사용하여 인코딩되고, 인코딩된 값이 사용자 이름으로 사용된다. 클라이언트 시크릿도 같은 알고리즘으로 인코딩되어 비밀번호로 사용된다.¶

이는 [RFC7591]의 Section 2에 정의된 client_secret_basic으로도 알려져 있다.¶

예(표시 목적의 추가 줄바꿈 포함):¶

Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

참고: 클라이언트 식별자와 시크릿을 먼저 폼 인코딩한 다음, 인코딩된 값을 HTTP Basic 인증 사용자 이름과 비밀번호로 사용하는 이 방법은 과거에 많은 상호 운용성 문제를 초래했다. 일부 구현은 인코딩 단계를 놓쳤거나, 특정 문자만 인코딩하기로 했거나, 자격 증명을 검증할 때 인코딩 요구사항을 무시하여, 클라이언트가 개별 권한 부여 서버에 자격 증명을 제시하는 방식을 특별 처리해야 했다. 요청 본문 콘텐츠에 자격 증명을 포함하면 인코딩 문제를 피하고 더 상호 운용 가능한 구현으로 이어진다.¶

클라이언트 시크릿 인증 방법에는 비밀번호가 포함되므로, 권한 부여 서버는 이를 사용하는 모든 엔드포인트를 무차별 대입 공격으로부터 보호해야 한다.¶

2.4.2. 기타 인증 방법

권한 부여 서버는 자신의 보안 요구사항과 일치하는 적절한 인증 스킴을 지원할 수 있다. 다른 인증 방법을 사용할 때, 권한 부여 서버는 클라이언트 식별자(등록 레코드)와 인증 스킴 간의 매핑을 정의해야 한다.¶

mTLS [RFC8705] 및 Private Key JWT ([RFC7523], [I-D.ietf-oauth-rfc7523bis]) 같은 일부 추가 인증 방법은 "OAuth Token Endpoint Authentication Methods" 레지스트리에 정의되어 있으며, 토큰 엔드포인트 보호라는 특정 사용을 넘어 일반적인 클라이언트 인증 방법으로도 유용할 수 있다.¶

3.2.1. 클라이언트 인증

기밀 클라이언트는 토큰 엔드포인트에 요청할 때 Section 2.4에 설명된 대로 권한 부여 서버에 인증해야 한다.¶

클라이언트 인증은 다음에 사용된다:¶

• 갱신 토큰과 권한 부여 코드를 그것들이 발급된 클라이언트에 바인딩하는 것을 집행한다. 클라이언트 인증은 권한 부여 코드가 안전하지 않은 채널을 통해 리디렉션 엔드포인트로 전송될 때 추가 보안 계층을 더한다.¶

• 클라이언트를 비활성화하거나 그 자격 증명을 변경하여 손상된 클라이언트로부터 복구하며, 이를 통해 공격자가 도난당한 갱신 토큰을 남용하지 못하게 한다. 단일 클라이언트 자격 증명 집합을 변경하는 것은 전체 갱신 토큰 집합을 취소하는 것보다 훨씬 빠르다.¶

• 정기적인 자격 증명 순환을 요구하는 인증 관리 모범 관행을 구현한다. 전체 갱신 토큰 집합의 순환은 어려울 수 있지만, 단일 클라이언트 자격 증명 집합의 순환은 훨씬 더 쉽다.¶

3.2.2. 토큰 엔드포인트 요청

클라이언트는 HTTP 요청 콘텐츠에서 UTF-8 문자 인코딩을 사용하고 Appendix C.2에 따른 폼 인코딩 직렬화 형식을 사용하여 다음 매개변수를 전송함으로써 토큰 엔드포인트에 요청한다:¶

"grant_type":

REQUIRED. 클라이언트가 특정 토큰 요청에서 사용하는 그랜트 유형의 식별자. 이 명세는 authorization_code, refresh_token, 및 client_credentials 값을 정의한다. 그랜트 유형은 토큰 요청에서 필요한 또는 지원되는 추가 매개변수를 결정한다. 이러한 그랜트 유형의 세부 사항은 아래에 정의되어 있다.¶

"client_id":

OPTIONAL. 매개변수에 의존하는 형태의 클라이언트 인증이 사용되거나, grant_type이 공개 클라이언트의 식별을 요구하는 경우 클라이언트 식별자가 필요하다.¶

기밀 클라이언트는 Section 3.2.1에 설명된 대로 권한 부여 서버에 인증해야 한다.¶

예를 들어, 클라이언트는 다음 HTTPS 요청을 수행한다 (표시 목적의 추가 줄바꿈 포함):¶

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&code_verifier=3641a2d12d66101249cdf7a79c000c1f8c05d2aafcf14bf146497bed

권한 부여 서버는 다음을 수행해야 한다:¶

• 기밀 클라이언트 (또는 다른 인증 요구사항이 있는 클라이언트)에 대해 클라이언트 인증을 요구한다,¶

• 클라이언트 인증이 포함된 경우 클라이언트를 인증한다¶

추가적인 그랜트 유형별 처리 규칙이 적용되며, 각각의 그랜트 유형과 함께 명시된다.¶

3.2.3. 토큰 엔드포인트 응답

접근 토큰 요청이 유효하고 권한 부여된 경우, 권한 부여 서버는 접근 토큰과 선택적 갱신 토큰을 발급한다.¶

클라이언트 인증이 실패했거나 유효하지 않은 경우, 권한 부여 서버는 Section 3.2.4에 설명된 오류 응답을 반환한다.¶

권한 부여 서버는 Appendix C.3에 따라 HTTP 응답을 생성하고, [RFC8259]에 정의된 application/json 미디어 유형을 사용하며, 다음 매개변수와 HTTP 200 (OK) 상태 코드를 포함하여 접근 토큰과 선택적 갱신 토큰을 발급한다:¶

"access_token":

REQUIRED. 권한 부여 서버가 발급한 접근 토큰.¶

"token_type":

REQUIRED. Section 1.4에 설명된 대로 발급된 접근 토큰의 유형. 값은 대소문자를 구분하지 않는다.¶

"expires_in":

RECOMMENDED. 접근 토큰의 수명을 초 단위로 나타내는 JSON 숫자. 예를 들어 값 3600은 접근 토큰이 응답이 생성된 시점부터 한 시간 후에 만료됨을 나타낸다. 생략된 경우 권한 부여 서버는 다른 수단으로 수명을 제공하거나 기본값을 문서화해야 한다. 권한 부여 서버가 접근 토큰을 조기에 만료시킬 수 있으며, 클라이언트는 제공된 수명 동안 접근 토큰이 유효할 것이라고 기대해서는 안 된다는 점에 유의한다.¶

"scope":

클라이언트가 요청한 범위와 동일한 경우 RECOMMENDED, 그렇지 않으면 REQUIRED. 접근 토큰의 범위는 Section 1.4.1에 설명된 대로이다.¶

"refresh_token":

OPTIONAL. 해당 토큰 요청에 전달된 그랜트를 기반으로 새 접근 토큰을 얻는 데 사용할 수 있는 갱신 토큰.¶

권한 부여 서버는 위험 평가와 자체 정책에 따라 특정 클라이언트에 갱신 토큰을 발급할지 결정해야 한다. 권한 부여 서버가 갱신 토큰을 발급하지 않기로 결정한 경우, 클라이언트는 예를 들어 새 권한 부여 코드 요청을 시작하는 것처럼 OAuth 흐름을 다시 시작하여 새 접근 토큰을 얻을 수 있다. 이러한 경우 권한 부여 서버는 사용자 경험을 최적화하기 위해 쿠키와 지속 그랜트를 사용할 수 있다.¶

갱신 토큰이 발급되는 경우, 해당 갱신 토큰은 리소스 소유자가 동의한 범위와 리소스 서버에 바인딩되어야 한다. 이는 합법적인 클라이언트에 의한 권한 상승을 방지하고 갱신 토큰 유출의 영향을 줄이기 위함이다.¶

매개변수는 Appendix C.3에 설명된 대로 JavaScript Object Notation (JSON) 구조로 직렬화된다.¶

권한 부여 서버는 토큰, 자격 증명 또는 기타 민감한 정보를 포함하는 모든 응답에 값이 no-store인 HTTP Cache-Control 응답 헤더 필드 ([RFC9111]의 Section 5.2 참조)를 포함해야 한다.¶

예:¶

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
  "example_parameter": "example_value"
}

클라이언트는 응답에서 인식되지 않은 값 이름을 무시해야 한다. 권한 부여 서버에서 받은 토큰 및 기타 값의 크기는 정의되지 않는다. 클라이언트는 값 크기에 대해 가정하지 않아야 한다. 권한 부여 서버는 자신이 발급하는 모든 값의 크기를 문서화해야 한다.¶

3.2.4. 토큰 엔드포인트 오류 응답

권한 부여 서버는 HTTP 400 (Bad Request) 상태 코드(달리 명시되지 않는 한)로 응답하고 다음 매개변수를 응답에 포함한다:¶

"error":

REQUIRED. 다음 중 하나의 단일 ASCII [USASCII] 오류 코드:¶

"invalid_request":

요청에 필수 매개변수가 없거나, 지원되지 않는 매개변수 값(그랜트 유형 제외)이 포함되어 있거나, 매개변수가 반복되거나, 여러 자격 증명이 포함되어 있거나, 클라이언트 인증에 둘 이상의 메커니즘을 사용하거나, 권한 부여 요청에서 code_challenge가 전송되지 않았음에도 code_verifier를 포함하거나, 그 밖에 형식이 잘못된 경우.¶

"invalid_client":

클라이언트 인증이 실패했다 (예: 알 수 없는 클라이언트, 클라이언트 인증이 포함되지 않음, 또는 지원되지 않는 인증 방법). 권한 부여 서버는 어떤 HTTP 인증 스킴이 지원되는지 나타내기 위해 HTTP 401 (Unauthorized) 상태 코드를 반환할 수 있다. 클라이언트가 Authorization 요청 헤더 필드를 통해 인증을 시도한 경우, 권한 부여 서버는 HTTP 401 (Unauthorized) 상태 코드로 응답하고 클라이언트가 사용한 인증 스킴과 일치하는 WWW-Authenticate 응답 헤더 필드를 포함해야 한다.¶

"invalid_grant":

제공된 권한 부여 그랜트 (예: 권한 부여 코드, 리소스 소유자 자격 증명) 또는 갱신 토큰이 유효하지 않거나, 만료되었거나, 취소되었거나, 권한 부여 요청에 사용된 리디렉션 URI와 일치하지 않거나, 다른 클라이언트에 발급된 경우.¶

"unauthorized_client":

인증된 클라이언트가 이 권한 부여 그랜트 유형을 사용할 권한이 없는 경우.¶

"unsupported_grant_type":

권한 부여 그랜트 유형이 권한 부여 서버에서 지원되지 않는 경우.¶

"invalid_scope":

요청된 범위가 유효하지 않거나, 알 수 없거나, 형식이 잘못되었거나, 리소스 소유자가 부여한 범위를 초과한 경우.¶

error 매개변수의 값은 집합 %x20-21 / %x23-5B / %x5D-7E 밖의 문자를 포함해서는 안 된다.¶

"error_description":

OPTIONAL. 발생한 오류를 클라이언트 개발자가 이해하는 데 도움을 주기 위해 추가 정보를 제공하는 사람이 읽을 수 있는 ASCII [USASCII] 텍스트. error_description 매개변수의 값은 집합 %x20-21 / %x23-5B / %x5D-7E 밖의 문자를 포함해서는 안 된다.¶

"error_uri":

OPTIONAL. 오류에 대한 정보가 있는 사람이 읽을 수 있는 웹 페이지를 식별하는 URI로, 클라이언트 개발자에게 오류에 대한 추가 정보를 제공하는 데 사용된다. error_uri 매개변수의 값은 URI-reference 구문을 따라야 하므로 집합 %x21 / %x23-5B / %x5D-7E 밖의 문자를 포함해서는 안 된다.¶

매개변수는 Appendix C.3에 정의된 application/json 미디어 유형을 사용하여 HTTP 응답의 콘텐츠에 포함된다.¶

예:¶

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
 "error": "invalid_request"
}

4.1.1. 권한 부여 요청

권한 부여 요청을 시작하기 위해 클라이언트는 권한 부여 서버의 권한 부여 엔드포인트 URI에 매개변수를 추가하여 권한 부여 요청 URI를 구성한다. 클라이언트는 결국 요청을 시작하기 위해 사용자 에이전트를 이 URI로 리디렉션한다.¶

클라이언트는 권한 부여 코드 주입 및 CSRF 공격을 방지하기 위해 권한 부여 요청마다 "코드 검증자"라고 하는 고유한 비밀을 사용한다. 클라이언트는 먼저 코드 검증자를 생성한 다음, 권한 부여 요청에 포함할 "코드 챌린지"를 파생한다. 클라이언트는 토큰 엔드포인트에서 권한 부여 코드를 교환할 때 코드 검증자를 사용하여 권한 부여 코드를 사용하는 클라이언트가 그것을 요청한 동일한 클라이언트임을 증명한다.¶

클라이언트는 Appendix C.1에 설명된 대로 권한 부여 엔드포인트 URI의 쿼리 구성 요소에 다음 매개변수를 추가하여 요청 URI를 구성한다:¶

"response_type":

REQUIRED. 권한 부여 엔드포인트는 서로 다른 요청 및 응답 매개변수 집합을 지원한다. 클라이언트는 특정 response_type 값을 사용하여 흐름 유형을 결정한다. 이 명세는 code 값을 정의하며, 이는 클라이언트가 권한 부여 코드 흐름을 사용하려 함을 나타내기 위해 사용되어야 한다.¶

확장 응답 유형은 값의 순서가 중요하지 않은 공백 구분(%x20) 값 목록을 포함할 수 있다 (예: 응답 유형 a b는 b a와 동일하다). 이러한 복합 응답 유형의 의미는 각 명세에서 정의된다.¶

일부 확장 응답 유형은 [OpenID.Connect]에서 정의된다.¶

권한 부여 요청에 response_type 매개변수가 없거나, 응답 유형을 이해할 수 없는 경우, 권한 부여 서버는 Section 4.1.2.1에 설명된 대로 오류 응답을 반환해야 한다.¶

"client_id":

REQUIRED. Section 2.2에 설명된 클라이언트 식별자.¶

"code_challenge":

Section 7.5.1의 특정 요구사항이 충족되지 않는 한 REQUIRED. 코드 검증자에서 파생된 코드 챌린지.¶

"code_challenge_method":

OPTIONAL, 요청에 없으면 기본값은 plain이다. 코드 검증자 변환 방법은 S256 또는 plain이다.¶

"redirect_uri":

이 클라이언트에 하나의 리디렉션 URI만 등록된 경우 OPTIONAL. 이 클라이언트에 여러 리디렉션 URI가 등록된 경우 REQUIRED. Section 2.3.2를 참조한다.¶

"scope":

OPTIONAL. Section 1.4.1에 설명된 접근 요청의 범위.¶

"state":

OPTIONAL. 요청과 콜백 사이에서 상태를 유지하기 위해 클라이언트가 사용하는 불투명한 값. 권한 부여 서버는 사용자 에이전트를 클라이언트로 다시 리디렉션할 때 이 값을 포함한다.¶

code_verifier는 각 권한 부여 요청에 대해 생성되는 고유하고 엔트로피가 높은 암호학적 난수 문자열이며, 예약되지 않은 문자 [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~"를 사용하고, 최소 길이는 43자, 최대 길이는 128자이다.¶

클라이언트는 code_verifier를 임시로 저장하고, 권한 부여 요청에서 사용할 code_challenge를 계산한다.¶

code_verifier의 ABNF는 다음과 같다.¶

code-verifier = 43*128unreserved
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39

클라이언트는 권한 부여 요청에서 code_verifier를 노출하지 않는 코드 챌린지 방법을 사용해야 한다. 그렇지 않으면 권한 부여 요청을 읽을 수 있는 공격자 ([RFC9700]의 공격자 A4 참조)가 이 메커니즘이 제공하는 보안을 깨뜨릴 수 있다. 현재 S256이 그러한 유일한 방법이다.¶

참고: 코드 검증자는 값을 추측하기 어렵게 만들 만큼 충분한 엔트로피를 가져야 한다. 적절한 난수 생성기의 출력을 사용하여 32옥텟 시퀀스를 만드는 것이 권장된다. 그런 다음 옥텟 시퀀스를 base64url 인코딩하여 코드 검증자로 사용할 43옥텟 URL 안전 문자열을 생성한다.¶

그런 다음 클라이언트는 코드 검증자에 대해 다음 변환 중 하나를 사용하여 코드 검증자에서 파생된 code_challenge를 만든다:¶

S256
  code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

plain
  code_challenge = code_verifier

클라이언트가 S256을 사용할 수 있다면 반드시 S256을 사용해야 한다. S256은 서버에서 구현 필수(MTI)이기 때문이다. 클라이언트는 해싱 함수를 사용할 수 없는 제약 환경처럼 어떤 기술적 이유로 S256을 지원할 수 없고, 대역 외 구성 또는 권한 부여 서버 메타데이터 [RFC8414]를 통해 서버가 plain을 지원함을 아는 경우에만 plain을 사용할 수 있다.¶

code_challenge의 ABNF는 다음과 같다.¶

code-challenge = 43*128unreserved
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39

code_challenge 및 code_verifier 속성은 이 기법이 처음 개발된 "Proof-Key for Code Exchange", 즉 PKCE [RFC7636]로 알려진 OAuth 2.0 확장에서 채택되었다.¶

권한 부여 서버는 code_challenge 및 code_verifier 매개변수를 지원해야 한다.¶

클라이언트는 code_challenge 및 code_verifier를 사용해야 하며, 권한 부여 서버는 Section 7.5.1에 설명된 조건을 제외하고 그 사용을 강제해야 한다. 이 경우에도 위에서 설명한 대로 code_challenge 및 code_verifier를 사용하고 강제하는 것이 여전히 권장된다.¶

state 및 scope 매개변수는 민감한 클라이언트 또는 리소스 소유자 정보를 평문으로 포함해서는 안 된다. 이들은 안전하지 않은 채널을 통해 전송되거나 안전하지 않게 저장될 수 있기 때문이다.¶

클라이언트는 HTTP 리디렉션 또는 사용자 에이전트를 통해 사용할 수 있는 다른 수단을 사용하여 리소스 소유자를 구성된 URI로 안내한다.¶

예를 들어, 클라이언트는 사용자 에이전트가 다음 HTTPS 요청을 하도록 안내한다(표시 목적의 추가 줄바꿈 포함):¶

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
    &code_challenge=6fdkQaPm51l13DSukcAH3Mdx7_ntecHYd1vi3n0hMZY
    &code_challenge_method=S256 HTTP/1.1
Host: server.example.com

권한 부여 서버는 모든 필수 매개변수가 있고 유효한지 확인하기 위해 요청을 검증한다.¶

특히, 권한 부여 서버는 요청에 redirect_uri가 있는 경우 이를 검증해야 하며, 클라이언트 등록(Section 2) 중 이전에 확립된 등록된 리디렉션 URI 중 하나와 일치하는지 확인해야 한다. 두 URI를 비교할 때 권한 부여 서버는 두 URI가 동일함을 보장해야 하며, 자세한 내용은 [RFC3986]의 Section 6.2.1, 단순 문자열 비교를 참조한다. 유일한 예외는 localhost URI를 사용하는 네이티브 앱이다. 이 경우 권한 부여 서버는 [RFC8252]의 Section 7.3에 설명된 대로 가변 포트 번호를 허용해야 한다.¶

요청이 유효하면, 권한 부여 서버는 리소스 소유자를 인증하고 (리소스 소유자에게 묻거나 다른 수단으로 승인을 확립하여) 권한 부여 결정을 얻는다.¶

결정이 확립되면, 권한 부여 서버는 HTTP 리디렉션 응답 또는 사용자 에이전트를 통해 사용할 수 있는 다른 수단을 사용하여 사용자 에이전트를 제공된 클라이언트 리디렉션 URI로 안내한다.¶

4.1.2. 권한 부여 응답

리소스 소유자가 접근 요청을 허용하면, 권한 부여 서버는 권한 부여 코드를 발급하고, 확장에서 달리 명시하지 않는 한 Appendix C.1에 설명된 쿼리 문자열 직렬화를 사용하여 리디렉션 URI의 쿼리 구성 요소에 다음 매개변수를 추가함으로써 이를 클라이언트에 전달한다:¶

"code":

REQUIRED. 권한 부여 코드는 권한 부여 서버가 생성하며 클라이언트에는 불투명하다. 권한 부여 코드는 유출 위험을 완화하기 위해 발급 직후 만료되어야 한다. 최대 권한 부여 코드 수명은 10분이 권장된다. 권한 부여 코드는 클라이언트 식별자, 코드 챌린지 및 리디렉션 URI에 바인딩된다.¶

"state":

클라이언트 권한 부여 요청에 state 매개변수가 있었다면 REQUIRED. 클라이언트에서 받은 정확한 값.¶

"iss":

OPTIONAL. 클라이언트가 둘 이상의 권한 부여 서버와 상호작용하는 경우 mix-up 공격을 방지하기 위해 사용할 수 있는 권한 부여 서버의 식별자. 이 매개변수가 필요한 경우와 클라이언트가 이를 사용하여 mix-up 공격을 방지하는 방법에 대한 추가 자세한 내용은 Section 7.14 및 [RFC9207]를 참조한다.¶

예를 들어, 권한 부여 서버는 다음 HTTP 응답을 전송하여 사용자 에이전트를 리디렉션한다:¶

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
          &state=xyz&iss=https%3A%2F%2Fauthorization-server.example.com

클라이언트는 인식되지 않은 응답 매개변수를 무시해야 한다. 권한 부여 코드 문자열 크기는 이 명세에서 정의되지 않는다. 클라이언트는 코드 값 크기에 대해 가정하지 않아야 한다. 권한 부여 서버는 자신이 발급하는 모든 값의 크기를 문서화해야 한다.¶

권한 부여 서버는 발급된 권한 부여 코드와 code_challenge 및 code_challenge_method 값을 연결해야 하며, 그래야 나중에 코드 챌린지를 검증할 수 있다.¶

서버가 발급된 코드와 code_challenge를 연결하는 정확한 방법은 이 명세의 범위를 벗어난다. 코드 챌린지는 서버에 저장되어 그곳에서 코드와 연결될 수 있다. code_challenge 및 code_challenge_method 값은 코드 자체에 암호화된 형태로 저장될 수 있지만, 서버는 AS가 아닌 엔터티가 추출할 수 있는 형태로 응답 매개변수에 code_challenge 값을 포함해서는 안 된다.¶

클라이언트는 공격자가 권한 부여 응답에 권한 부여 코드를 주입(재전송)하는 것을 방지해야 한다. code_challenge 및 code_verifier를 사용하면 권한 부여 서버가 일치하지 않는 code_verifier가 있는 토큰 요청을 거부하므로 권한 부여 코드 주입을 방지한다. 자세한 내용은 Section 7.5.1을 참조한다.¶

HTTP/1.1 302 Found
Location: https://client.example.com/cb?error=access_denied
          &state=xyz&iss=https%3A%2F%2Fauthorization-server.example.com

4.1.3. 토큰 엔드포인트 확장

권한 부여 그랜트 유형은 토큰 엔드포인트에서 grant_type 값 authorization_code로 식별된다.¶

이 값이 설정된 경우, Section 3.2.2 외에 다음 추가 토큰 요청 매개변수가 지원된다:¶

"code":

REQUIRED. 권한 부여 서버에서 받은 권한 부여 코드.¶

"code_verifier":

권한 부여 요청에 code_challenge 매개변수가 포함된 경우 REQUIRED. 그렇지 않으면 사용해서는 안 된다. 원래 코드 검증자 문자열.¶

"client_id":

클라이언트가 Section 3.2.1에 설명된 대로 권한 부여 서버에 인증하지 않는 경우 REQUIRED.¶

권한 부여 서버는 주어진 권한 부여 코드에 대해 접근 토큰을 한 번만 반환해야 한다.¶

이전에 성공한 토큰 요청과 동일한 권한 부여 코드로 두 번째 유효한 토큰 요청이 이루어지면, 권한 부여 서버는 요청을 거부해야 하며 (가능한 경우) 해당 권한 부여 코드를 기반으로 이전에 발급한 모든 접근 토큰과 갱신 토큰을 취소해야 한다. 자세한 내용은 Section 7.5.2를 참조한다.¶

예를 들어, 클라이언트는 다음 HTTPS 요청을 수행한다 (표시 목적의 추가 줄바꿈 포함):¶

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&code_verifier=3641a2d12d66101249cdf7a79c000c1f8c05d2aafcf14bf146497bed

Section 3.2.2의 처리 규칙 외에도, 권한 부여 서버는 다음을 수행해야 한다:¶

• 권한 부여 코드가 인증된 기밀 클라이언트에 발급되었는지 확인하거나, 클라이언트가 공개 클라이언트인 경우 코드가 요청의 client_id에 발급되었는지 확인한다,¶

• 권한 부여 코드가 유효한지 검증한다,¶

• code_verifier 매개변수가 권한 부여 요청에 code_challenge 매개변수가 있었던 경우에만 존재하는지 검증한다,¶

• code_verifier가 있는 경우, 수신한 code_verifier에서 코드 챌린지를 계산하고, 먼저 클라이언트가 지정한 code_challenge_method 방법에 따라 변환한 뒤, 이전에 연결된 code_challenge와 비교하여 code_verifier를 검증한다, 그리고¶

• 토큰 요청의 권한 부여 코드와 연결된 권한 부여 요청에 code_challenge가 없었다면, 권한 부여 서버는 토큰 요청을 거부해야 한다.¶

토큰 요청의 redirect_uri 매개변수와 관련하여 OAuth 2.0 클라이언트와의 하위 호환성에 대한 자세한 내용은 Section 10.2를 참조한다.¶

4.2.1. 토큰 엔드포인트 확장

클라이언트 자격 증명 그랜트 유형은 토큰 엔드포인트에서 grant_type 값 client_credentials로 식별된다.¶

이 값이 설정된 경우, Section 3.2.2 외에 다음 추가 토큰 요청 매개변수가 지원된다:¶

"scope":

OPTIONAL. Section 1.4.1에 설명된 접근 요청의 범위.¶

예를 들어, 클라이언트는 전송 계층 보안을 사용하여 다음 HTTP 요청을 수행한다(표시 목적의 추가 줄바꿈 포함):¶

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

권한 부여 서버는 클라이언트를 인증해야 한다.¶

4.3.1. 토큰 엔드포인트 확장

갱신 토큰 그랜트 유형은 토큰 엔드포인트에서 grant_type 값 refresh_token으로 식별된다.¶

이 값이 설정된 경우, Section 3.2.2 외에 다음 추가 매개변수가 지원된다:¶

"refresh_token":

REQUIRED. 클라이언트에 발급된 갱신 토큰.¶

"scope":

OPTIONAL. Section 1.4.1에 설명된 접근 요청의 범위. 요청된 범위는 리소스 소유자가 원래 부여하지 않은 범위를 포함해서는 안 되며, 생략된 경우 리소스 소유자가 원래 부여한 범위와 동일한 것으로 처리된다.¶

갱신 토큰은 일반적으로 추가 접근 토큰을 요청하는 데 사용되는 장기 지속 자격 증명이므로, 갱신 토큰은 그것이 발급된 클라이언트에 바인딩된다. 기밀 클라이언트는 Section 3.2.1에 설명된 대로 권한 부여 서버에 인증해야 한다.¶

예를 들어, 클라이언트는 전송 계층 보안을 사용하여 다음 HTTP 요청을 수행한다(표시 목적의 추가 줄바꿈 포함):¶

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

Section 3.2.2의 처리 규칙 외에도, 권한 부여 서버는 다음을 수행해야 한다:¶

• 요청에 클라이언트 인증이 포함된 경우, 갱신 토큰이 인증된 클라이언트에 발급되었는지 확인하거나, 요청에 client_id가 포함된 경우 갱신 토큰이 일치하는 클라이언트에 발급되었는지 확인한다¶

• 이 갱신 토큰에 해당하는 그랜트가 여전히 활성 상태인지 검증한다¶

• 갱신 토큰을 검증한다¶

권한 부여 서버는 공개 클라이언트에 대해 악의적 행위자에 의한 갱신 토큰 재전송을 탐지하기 위해 다음 방법 중 하나를 사용해야 한다:¶

• 발신자 제한 갱신 토큰: 권한 부여 서버는 예를 들어 DPoP [RFC9449] 또는 mTLS [RFC8705]를 활용하여 갱신 토큰을 특정 클라이언트 인스턴스에 암호학적으로 바인딩한다.¶

• 갱신 토큰 순환: 권한 부여 서버는 접근 토큰 갱신 응답마다 새 갱신 토큰을 발급한다. 이전 갱신 토큰은 무효화되지만, 관계에 대한 정보는 권한 부여 서버에 유지된다. 갱신 토큰이 손상되고 이후 공격자와 합법적인 클라이언트가 모두 사용하면, 둘 중 하나가 무효화된 갱신 토큰을 제시하게 되며, 이는 권한 부여 서버에 침해 사실을 알린다. 권한 부여 서버는 어느 당사자가 유효하지 않은 갱신 토큰을 제출했는지 판단할 수 없지만, 활성 갱신 토큰과 그에 연결된 접근 권한 부여 그랜트도 취소한다. 이는 합법적인 클라이언트가 새로운 권한 부여 그랜트를 얻어야 하는 비용으로 공격을 중단시킨다.¶

구현 참고: 갱신 토큰이 속한 그랜트는 갱신 토큰 자체에 인코딩될 수 있다. 이는 권한 부여 서버가 갱신 토큰이 속한 그랜트를 효율적으로 결정하고, 나아가 취소되어야 하는 모든 갱신 토큰을 결정할 수 있게 한다. 이 경우 권한 부여 서버는 예를 들어 서명을 사용하여 갱신 토큰 값의 무결성을 보장해야 한다.¶

4.3.2. 갱신 토큰 응답

유효하고 권한 부여된 경우, 권한 부여 서버는 Section 3.2.3에 설명된 대로 접근 토큰을 발급한다.¶

권한 부여 서버는 새 갱신 토큰을 발급할 수 있으며, 이 경우 클라이언트는 이전 갱신 토큰을 버리고 새 갱신 토큰으로 교체해야 한다.¶

4.3.3. 갱신 토큰 권장사항

권한 부여 서버는 클라이언트에 새 갱신 토큰을 발급한 후 이전 갱신 토큰을 취소할 수 있다. 새 갱신 토큰이 발급되는 경우, 갱신 토큰 범위는 클라이언트가 요청에 포함한 갱신 토큰의 범위와 동일해야 한다.¶

권한 부여 서버는 다음과 같은 보안 이벤트가 발생한 경우 갱신 토큰을 자동으로 취소할 수 있다:¶

• 비밀번호 변경¶

• 권한 부여 서버에서 로그아웃¶

클라이언트가 일정 시간 동안 비활성 상태인 경우, 즉 갱신 토큰이 일정 시간 동안 새 접근 토큰을 얻는 데 사용되지 않은 경우, 갱신 토큰은 만료되어야 한다. 만료 시간은 권한 부여 서버의 재량에 따른다. 이는 전역 값일 수도 있고, 클라이언트 정책 또는 갱신 토큰에 연결된 그랜트(및 그 민감도)에 따라 결정될 수도 있다.¶

5.1.1. Authorization 요청 헤더 필드

HTTP/1.1 [RFC7235]에 정의된 Authorization 요청 헤더 필드에 접근 토큰을 보낼 때, 클라이언트는 Bearer 스킴을 사용하여 접근 토큰을 전송한다.¶

예:¶

 GET /resource HTTP/1.1
 Host: server.example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

이 스킴의 Authorization 헤더 필드 구문은 [RFC2617]의 Section 2에 정의된 Basic 스킴의 사용법을 따른다. Basic과 마찬가지로 [RFC2617]의 Section 1.2에 정의된 일반 구문을 따르지는 않지만, HTTP 1.1 Authentication [RFC7235]의 일반 인증 프레임워크와 호환된다. 다만 기존 배포를 반영하기 위해 그 안에 제시된 선호 관행을 따르지는 않는다. Bearer 자격 증명의 구문은 다음과 같다:¶

token68    = 1*( ALPHA / DIGIT /
                 "-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "bearer" 1*SP token68

클라이언트는 Authorization 요청 헤더 필드와 Bearer HTTP 권한 부여 스킴을 사용하여 bearer 토큰으로 인증된 요청을 해야 한다. 리소스 서버는 이 방법을 지원해야 한다.¶

[RFC9110]의 Section 11.1에 설명된 대로, 문자열 bearer는 대소문자를 구분하지 않는다. 이는 다음 모두가 Authorization 헤더의 유효한 사용임을 의미한다:¶

• Authorization: Bearer mF_9.B5f-4.1JqM¶

• Authorization: bearer mF_9.B5f-4.1JqM¶

• Authorization: BEARER mF_9.B5f-4.1JqM¶

• Authorization: bEaReR mF_9.B5f-4.1JqM¶

5.1.2. 폼 인코딩 콘텐츠 매개변수

HTTP 요청 콘텐츠에 접근 토큰을 보낼 때, 클라이언트는 access_token 매개변수를 사용하여 요청 콘텐츠에 접근 토큰을 추가한다. 클라이언트는 다음 조건이 모두 충족되지 않는 한 이 방법을 사용해서는 안 된다:¶

• HTTP 요청에 Content-Type 헤더 필드가 포함되어 있고 application/x-www-form-urlencoded로 설정되어 있다.¶

• 콘텐츠는 URL Living Standard [WHATWG.URL]에 정의된 application/x-www-form-urlencoded content-type의 인코딩 요구사항을 따른다.¶

• HTTP 요청 콘텐츠는 단일 파트이다.¶

• 요청에 인코딩될 콘텐츠는 전적으로 ASCII [USASCII] 문자로 구성되어야 한다.¶

• HTTP 요청 메서드는 콘텐츠에 대해 정의된 의미를 가진 것이어야 한다. 특히 이는 GET 메서드를 사용해서는 안 됨을 의미한다.¶

콘텐츠에는 다른 요청별 매개변수가 포함될 수 있으며, 이 경우 access_token 매개변수는 & 문자(ASCII 코드 38)를 사용하여 요청별 매개변수와 적절히 구분되어야 한다.¶

예를 들어, 클라이언트는 전송 계층 보안을 사용하여 다음 HTTP 요청을 수행한다:¶

POST /resource HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

access_token=mF_9.B5f-4.1JqM

application/x-www-form-urlencoded 방법은 참여 클라이언트가 Authorization 요청 헤더 필드에 접근할 수 없는 애플리케이션 맥락을 제외하고는 사용하지 않는 것이 좋다. 리소스 서버는 이 방법을 지원할 수 있다.¶

5.3.1. WWW-Authenticate 응답 헤더 필드

보호된 리소스 요청에 인증 자격 증명이 포함되어 있지 않거나, 보호된 리소스에 대한 접근을 가능하게 하는 접근 토큰이 포함되어 있지 않은 경우, 리소스 서버는 HTTP WWW-Authenticate 응답 헤더 필드를 포함해야 한다. 다른 조건에 대한 응답에도 이를 포함할 수 있다. WWW-Authenticate 헤더 필드는 HTTP/1.1 [RFC7235]에 정의된 프레임워크를 사용한다.¶

이 토큰 유형에 대한 모든 챌린지는 auth-scheme 값 Bearer를 사용해야 한다. 이 스킴 뒤에는 하나 이상의 auth-param 값이 따라야 한다. 이 토큰 유형에 대해 이 명세가 사용하거나 정의하는 auth-param 속성은 다음과 같다. 다른 auth-param 속성도 사용할 수 있다.¶

"realm":

realm 속성은 HTTP/1.1 [RFC7235]에 설명된 방식으로 보호 범위를 나타내기 위해 포함될 수 있다. realm 속성은 두 번 이상 나타나서는 안 된다.¶

"scope":

scope 속성은 Section 1.4.1에 정의되어 있다. scope 속성은 요청된 리소스에 접근하기 위해 접근 토큰에 필요한 범위를 나타내는, 공백으로 구분된 대소문자 구분 범위 값 목록이다. scope 값은 구현에서 정의하며, 중앙 집중식 레지스트리는 없고, 허용되는 값은 권한 부여 서버가 정의한다. scope 값의 순서는 중요하지 않다. 일부 경우에는 보호된 리소스를 사용할 충분한 접근 범위를 가진 새 접근 토큰을 요청할 때 scope 값이 사용된다. scope 속성의 사용은 OPTIONAL이다. scope 속성은 두 번 이상 나타나서는 안 된다. scope 값은 프로그래밍 방식 사용을 위한 것이며 최종 사용자에게 표시하기 위한 것이 아니다.¶

두 가지 예시 scope 값은 다음과 같다. 이들은 각각 OpenID Connect [OpenID.Messages] 및 Open Authentication Technology Committee (OATC) Online Multimedia Authorization Protocol [OMAP] OAuth 2.0 사용 사례에서 가져온 것이다:¶

scope="openid profile email"
scope="urn:example:channel=HBO&urn:example:rating=G,PG-13"

¶

"error":

보호된 리소스 요청에 접근 토큰이 포함되어 있었고 인증에 실패한 경우, 리소스 서버는 접근 요청이 거절된 이유를 클라이언트에 제공하기 위해 error 속성을 포함해야 한다. 매개변수 값은 Section 5.3.2에 설명되어 있다.¶

"error_description":

리소스 서버는 최종 사용자에게 표시하기 위한 것이 아닌, 개발자를 위한 사람이 읽을 수 있는 설명을 제공하기 위해 error_description 속성을 포함할 수 있다.¶

"error_uri":

리소스 서버는 오류를 설명하는 사람이 읽을 수 있는 웹 페이지를 식별하는 절대 URI와 함께 error_uri 속성을 포함할 수 있다.¶

error, error_description, 및 error_uri 속성은 두 번 이상 나타나서는 안 된다.¶

Appendix A.4에 지정된 scope 속성의 값은 범위 값을 나타내기 위한 집합 %x21 / %x23-5B / %x5D-7E 및 범위 값 사이의 구분자로 쓰이는 %x20 밖의 문자를 포함해서는 안 된다. Appendix A.7 및 Appendix A.8에 지정된 error 및 error_description 속성의 값은 집합 %x20-21 / %x23-5B / %x5D-7E 밖의 문자를 포함해서는 안 된다. Appendix A.9에 지정된 error_uri 속성의 값은 URI-reference 구문을 따라야 하므로 집합 %x21 / %x23-5B / %x5D-7E 밖의 문자를 포함해서는 안 된다.¶

5.3.2. 오류 코드

요청이 실패하면, 리소스 서버는 적절한 HTTP 상태 코드 (일반적으로 400, 401, 403 또는 405)를 사용하여 응답하고 응답에 다음 오류 코드 중 하나를 포함한다:¶

"invalid_request":

요청에 필수 매개변수가 없거나, 지원되지 않는 매개변수 또는 매개변수 값이 포함되어 있거나, 동일한 매개변수가 반복되거나, 접근 토큰을 포함하기 위해 둘 이상의 방법을 사용하거나, 그 밖에 형식이 잘못된 경우. 리소스 서버는 HTTP 400 (Bad Request) 상태 코드로 응답해야 한다.¶

"invalid_token":

제공된 접근 토큰이 만료되었거나, 취소되었거나, 형식이 잘못되었거나, 기타 이유로 유효하지 않은 경우. 리소스 서버는 HTTP 401 (Unauthorized) 상태 코드로 응답해야 한다. 클라이언트는 새 접근 토큰을 요청하고 보호된 리소스 요청을 다시 시도할 수 있다.¶

"insufficient_scope":

요청이 클라이언트에 부여되고 접근 토큰으로 표현된 범위가 제공하는 것보다 더 높은 권한(범위)을 요구하는 경우. 리소스 서버는 HTTP 403 (Forbidden) 상태 코드로 응답해야 하며, 보호된 리소스에 접근하는 데 필요한 범위와 함께 scope 속성을 포함할 수 있다.¶

확장은 추가 오류 코드를 정의하거나 위 오류 코드가 반환되는 추가 상황을 지정할 수 있다.¶

요청에 인증 정보가 없는 경우 (예: 클라이언트가 인증이 필요하다는 것을 몰랐거나 지원되지 않는 인증 방법을 사용하여 시도한 경우), 리소스 서버는 오류 코드나 기타 오류 정보를 포함하지 않는 것이 좋다.¶

예:¶

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

그리고 만료된 접근 토큰을 사용한 인증 시도가 있는 보호된 리소스 요청에 대한 응답:¶

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                  error="invalid_token",
                  error_description="The access token expired"

6.1.1. 등록된 접근 토큰 유형

[RFC6750]은 OAuth 토큰 인증 스킴 간에 공유할 오류 값을 위한 공통 레지스트리를 [RFC6749]의 Section 11.4에서 확립한다.¶

주로 OAuth 토큰 인증을 위해 설계된 새 인증 스킴은 클라이언트에 오류 상태 코드를 제공하는 메커니즘을 정의해야 하며, 허용되는 오류 값은 이 명세가 확립한 오류 레지스트리에 등록된다.¶

그러한 스킴은 유효한 오류 코드 집합을 등록된 값의 하위 집합으로 제한할 수 있다. 오류 코드가 명명된 매개변수를 사용하여 반환되는 경우, 매개변수 이름은 error여야 한다.¶

OAuth 토큰 인증에 사용될 수 있지만 주로 그 목적을 위해 설계되지는 않은 다른 스킴도 같은 방식으로 오류 값을 레지스트리에 바인딩할 수 있다.¶

새 인증 스킴은 이 명세에서의 사용과 병렬적인 방식으로 오류 정보를 반환하기 위해 error_description 및 error_uri 매개변수의 사용도 지정하도록 선택할 수 있다.¶

유형 이름은 type-name ABNF를 따라야 한다. 유형 정의가 새 HTTP 인증 스킴을 포함하는 경우, 유형 이름은 HTTP 인증 스킴 이름 ([RFC2617]에 정의된 대로)과 동일해야 한다. 토큰 유형 example은 예제 사용을 위해 예약된다.¶

type-name  = 1*name-char
name-char  = "-" / "." / "_" / DIGIT / ALPHA

6.1.2. 벤더별 접근 토큰 유형

URI 이름을 사용하는 유형은 일반적으로 적용되지 않고 사용되는 리소스 서버의 구현 세부 사항에 특정한 벤더별 구현으로 제한되어야 한다.¶

그 밖의 모든 유형은 등록되어야 한다.¶

7.1.1. 보안 위협

다음 목록은 어떤 형태의 토큰을 사용하는 프로토콜에 대한 여러 일반적인 위협을 제시한다. 이 위협 목록은 NIST Special Publication 800-63 [NIST800-63]에 기반한다.¶

7.1.2. 위협 완화

접근 토큰의 콘텐츠를 디지털 서명을 사용하여 보호하고, 정기적 키 순환 같은 서명 키 관리 모범 관행을 따르면 광범위한 위협을 완화할 수 있다.¶

또는 bearer 토큰은 권한 부여 정보를 직접 인코딩하는 대신 권한 부여 정보에 대한 참조를 포함할 수 있다. 참조를 사용하려면 참조를 권한 부여 정보로 해석하기 위해 리소스 서버와 권한 부여 서버 사이의 추가 상호작용이 필요할 수 있다. 그러한 상호작용의 메커니즘은 이 명세에서 정의하지 않지만, 그러한 메커니즘 중 하나는 Token Introspection [RFC7662]에 정의되어 있다.¶

이 문서는 접근 토큰의 인코딩이나 콘텐츠를 지정하지 않는다. 따라서 접근 토큰 무결성 보호를 보장하는 수단에 대한 상세 권장사항은 이 명세의 범위를 벗어난다. 접근 토큰의 인코딩 및 서명 메커니즘의 한 예는 JSON Web Token Profile for Access Tokens [RFC9068]에 설명되어 있다.¶

접근 토큰 리디렉션을 다루기 위해서는, 권한 부여 서버가 토큰에 의도된 수신자(대상)의 신원을, 일반적으로 단일 리소스 서버(또는 리소스 서버 목록)를 포함하는 것이 중요하다. 토큰의 사용을 특정 범위로 제한하는 것도 권장된다.¶

Section 1.5는 접근 토큰 공개로부터 보호하고 클라이언트, 리소스 서버 및 권한 부여 서버 간의 통신에 기밀성과 무결성을 제공하기 위한 정보를 제공한다.¶

7.1.3. 권장사항 요약

7.1.4. 접근 토큰 권한 제한

접근 토큰과 연결된 권한은 특정 애플리케이션 또는 사용 사례에 필요한 최소한으로 제한되어야 한다. 이는 클라이언트가 리소스 소유자가 권한 부여한 권한을 초과하는 것을 방지한다. 또한 사용자가 각 보안 정책에서 권한 부여한 권한을 초과하는 것도 방지한다. 권한 제한은 접근 토큰 유출의 영향을 줄이는 데도 도움이 된다.¶

특히 접근 토큰은 특정 리소스 서버 (대상 제한), 가능하면 단일 리소스 서버로 제한되어야 한다. 이를 실행하기 위해 권한 부여 서버는 접근 토큰을 특정 리소스 서버와 연결하고, 모든 리소스 서버는 각 요청에 대해 해당 요청과 함께 전송된 접근 토큰이 그 특정 리소스 서버에 사용되도록 의도된 것인지 검증할 의무가 있다. 그렇지 않은 경우, 리소스 서버는 해당 요청을 처리하기를 거부해야 한다. 클라이언트와 권한 부여 서버는 접근하려는 리소스 서버를 결정하기 위해 이 문서 및 [RFC8707]에 각각 지정된 scope 또는 resource 매개변수를 사용할 수 있다.¶

또한 접근 토큰은 리소스 서버의 특정 리소스 및 동작 또는 리소스로 제한되어야 한다. 이를 실행하기 위해 권한 부여 서버는 접근 토큰을 해당 리소스 및 동작과 연결하고, 모든 리소스 서버는 각 요청에 대해 그 요청과 함께 전송된 접근 토큰이 특정 리소스에 대한 특정 동작에 사용되도록 의도된 것인지 검증할 의무가 있다. 그렇지 않은 경우, 리소스 서버는 해당 요청을 처리하기를 거부해야 한다. 클라이언트와 권한 부여 서버는 그러한 리소스 및/또는 동작을 결정하기 위해 [RFC9396]에 지정된 scope 및 authorization_details 매개변수를 사용할 수 있다.¶

7.3.1. 네이티브 앱 가장

위에서 언급한 대로, 권한 부여 서버는 클라이언트의 신원을 보장할 수 있는 경우를 제외하고 사용자 동의나 상호작용 없이 권한 부여 요청을 자동으로 처리해서는 안 된다. 여기에는 사용자가 이전에 주어진 클라이언트 ID에 대해 권한 부여 요청을 승인한 경우도 포함된다. 클라이언트의 신원을 증명할 수 없는 한, 해당 요청은 이전에 승인된 요청이 없었던 것처럼 처리되어야 한다.¶

claimed https 스킴 리디렉션 같은 조치는 권한 부여 서버가 신원 증명으로 수락할 수 있다. 일부 운영 체제는 적절한 경우 수락될 수 있는 대체 플랫폼별 신원 기능을 제공할 수 있다.¶

7.3.2. 접근 토큰 권한 제한

클라이언트는 필요한 최소 범위로 접근 토큰을 요청해야 한다. 권한 부여 서버는 요청된 범위를 어떻게 승인할지 선택할 때 클라이언트 신원을 고려해야 하며, 요청된 것보다 적은 범위의 접근 토큰을 발급할 수 있다.¶

접근 토큰과 연결된 권한은 특정 애플리케이션 또는 사용 사례에 필요한 최소한으로 제한되어야 한다. 이는 클라이언트가 리소스 소유자가 권한 부여한 권한을 초과하는 것을 방지한다. 또한 사용자가 각 보안 정책에서 권한 부여한 권한을 초과하는 것도 방지한다. 권한 제한은 접근 토큰 유출의 영향을 줄이는 데도 도움이 된다.¶

특히 접근 토큰은 특정 리소스 서버(대상 제한), 가능하면 단일 리소스 서버로 제한되어야 한다. 이를 실행하기 위해 권한 부여 서버는 접근 토큰을 특정 리소스 서버와 연결하고, 모든 리소스 서버는 각 요청에 대해 해당 요청과 함께 전송된 접근 토큰이 그 특정 리소스 서버에 사용되도록 의도된 것인지 검증할 의무가 있다. 그렇지 않은 경우 리소스 서버는 해당 요청을 처리하기를 거부해야 한다. 클라이언트와 권한 부여 서버는 접근하려는 리소스 서버를 결정하기 위해 [RFC8707]에 각각 지정된 scope 또는 resource 매개변수를 사용할 수 있다.¶

7.5.1. 권한 부여 코드 주입

권한 부여 코드 주입은 클라이언트가 합법적인 권한 부여 서버의 권한 부여 코드 대신 공격자로부터 온 권한 부여 코드를 리디렉션 URI에서 받는 공격이다. 보호 조치가 없으면, 클라이언트가 공격이 발생했음을 알 수 있는 메커니즘이 없다. 권한 부여 코드 주입은 공격자가 피해자의 계정에 접근하게 만들 수 있을 뿐 아니라, 피해자가 실수로 공격자의 계정에 접근하게 만들 수도 있다.¶

7.5.2. 권한 부여 코드 재사용

권한 부여 코드를 두 번 이상 사용할 수 있다면 여러 유형의 공격이 가능하다.¶

Section 4.1.3에 설명된 대로, 권한 부여 서버는 이미 접근 토큰을 발급하는 데 사용된 권한 부여 코드로 두 번째 유효한 요청을 받으면 토큰 요청을 거부하고 발급된 모든 토큰을 취소해야 한다. 공격자가 권한 부여 코드를 유출하여 합법적인 클라이언트보다 먼저 사용할 수 있다면, 공격자는 접근 토큰을 얻고 합법적인 클라이언트는 얻지 못한다. 발급된 모든 토큰을 취소하면 공격자의 토큰도 취소되어 공격이 더 진행되는 것을 막는다.¶

그러나 권한 부여 서버는 권한 부여 코드가 포함된 요청도 code_verifier 및 클라이언트 인증 같은 다른 매개변수를 포함하여 유효한 경우에만 발급된 토큰을 취소해야 한다. 권한 부여 서버는 유효하지 않은 매개변수를 포함하는 재전송된 권한 부여 코드를 받을 때 발급된 토큰을 취소해서는 안 된다. 그렇게 하면 권한 부여 코드를 얻을 수는 있지만 클라이언트 인증 또는 code_verifier를 얻을 수 없는 공격자가 합법적인 클라이언트보다 먼저 유효하지 않은 권한 부여 코드 요청을 보내 합법적인 클라이언트가 유효한 요청을 할 때 그 토큰을 취소하게 하는 서비스 거부 기회를 만들 수 있다.¶

7.5.3. HTTP 307 리디렉션

사용자 자격 증명을 포함할 가능성이 있는 요청을 리디렉션하는 권한 부여 서버는 리디렉션에 307 상태 코드 ([RFC9110]의 Section 15.4.8)를 사용해서는 안 된다. 그러한 요청에 HTTP 리디렉션(예: JavaScript가 아닌)이 사용되는 경우, AS는 상태 코드 303 ("See Other")을 사용해야 한다.¶

권한 부여 엔드포인트에서 일반적인 프로토콜 흐름은 AS가 사용자에게 양식에 자격 증명을 입력하도록 요청하고, 그 양식이 (POST 메서드를 사용하여) 권한 부여 서버로 다시 제출되는 것이다. AS는 자격 증명을 확인하고, 성공하면 사용자 에이전트를 클라이언트의 리디렉션 URI로 리디렉션한다.¶

리디렉션에 307 상태 코드가 사용되면, 사용자 에이전트는 POST 요청을 통해 사용자 자격 증명을 클라이언트로 전송한다.¶

이는 민감한 자격 증명을 클라이언트에 공개한다. 클라이언트가 악의적이라면, 그 자격 증명을 사용하여 AS에서 사용자를 가장할 수 있다.¶

이 동작은 개발자에게 예상 밖일 수 있지만, [RFC9110]의 Section 15.4.8에 정의되어 있다. 이 상태 코드는 사용자 에이전트가 POST 요청을 GET 요청으로 다시 작성하고 POST 요청 콘텐츠의 양식 데이터를 삭제하도록 요구하지 않는다.¶

HTTP [RFC9110]에서, 상태 코드 303만이 HTTP POST 요청을 HTTP GET 요청으로 다시 작성하도록 명확하게 강제한다. 인기 있는 302를 포함한 다른 모든 상태 코드의 경우, 사용자 에이전트는 POST를 GET 요청으로 다시 작성하지 않도록 선택할 수 있으며, 따라서 사용자 자격 증명을 클라이언트에 노출할 수 있다. (그러나 실제로는 대부분의 사용자 에이전트가 307 리디렉션에서만 이 동작을 보인다.)¶

7.12.1. 오픈 리디렉터로서의 클라이언트

클라이언트는 오픈 리디렉터를 노출해서는 안 된다. 공격자는 [RFC9700]의 Section 4.1.1에 설명된 대로 오픈 리디렉터를 사용하여 클라이언트를 가리키는 URL을 만들고 이를 활용하여 권한 부여 코드를 유출할 수 있다. 또 다른 남용 사례는 클라이언트를 가리키는 것처럼 보이는 URL을 만드는 것이다. 이는 사용자를 속여 URL을 신뢰하고 브라우저에서 따라가게 할 수 있다. 이는 피싱에 악용될 수 있다.¶

오픈 리디렉션을 방지하기 위해 클라이언트는 대상 URL이 허용 목록에 있거나 요청의 출처와 무결성을 인증할 수 있는 경우에만 리디렉션해야 한다. 오픈 리디렉션에 대한 대응책은 OWASP [owasp_redir]에서 설명한다.¶

7.12.2. 오픈 리디렉터로서의 권한 부여 서버

클라이언트의 경우와 마찬가지로, 공격자는 사용자가 권한 부여 서버(특히 그 URL)에 대해 가지는 신뢰를 피싱 공격 수행에 활용하려고 시도할 수 있다. OAuth 권한 부여 서버는 정기적으로 사용자를 다른 웹사이트(클라이언트)로 리디렉션하지만, 이를 안전하게 수행해야 한다.¶

Section 4.1.2.1은 이미 client_id와 redirect_uri의 조합이 유효하지 않은 경우 권한 부여 서버가 사용자 에이전트를 자동으로 리디렉션해서는 안 된다고 명시하여 오픈 리디렉션을 방지한다.¶

그러나 공격자는 올바르게 등록된 리디렉션 URI도 피싱 공격에 활용할 수 있다. 예를 들어 공격자는 동적 클라이언트 등록 [RFC7591]을 통해 클라이언트를 등록하고 다음 공격 중 하나를 실행할 수 있다:¶

1. 예를 들어 유효하지 않은 scope 값을 사용하여 의도적으로 잘못된 권한 부여 요청을 보내고, 따라서 권한 부여 서버가 사용자 에이전트를 자신의 피싱 사이트로 리디렉션하도록 지시한다.¶

2. 공격자가 제어하는 client_id 및 redirect_uri로 의도적으로 유효한 권한 부여 요청을 보낸다. 사용자가 인증한 후, 권한 부여 서버는 사용자에게 요청에 대한 동의를 제공하라고 요청한다. 사용자가 요청의 문제를 알아차리고 요청을 거부하더라도, 권한 부여 서버는 여전히 사용자 에이전트를 피싱 사이트로 리디렉션한다. 이 경우 사용자 에이전트는 사용자가 취한 동작과 관계없이 피싱 사이트로 리디렉션된다.¶

3. 공격자가 제어하는 client_id 및 redirect_uri로 의도적으로 유효한 무음 인증 요청(prompt=none)을 보낸다. 이 경우 권한 부여 서버는 사용자 에이전트를 피싱 사이트로 자동 리디렉션한다.¶

권한 부여 서버는 이러한 위협을 방지하기 위한 예방 조치를 취해야 한다. 권한 부여 서버는 항상 사용자를 먼저 인증해야 하며, 무음 인증 사용 사례를 제외하고, 필요할 때 사용자를 리디렉션하기 전에 자격 증명을 요청해야 한다. 권한 부여 서버는 위험 평가에 따라 리디렉션 URI를 신뢰할 수 있는지 여부를 결정해야 한다. 내부적으로 또는 외부 서비스를 통해 수행된 URI 분석을 고려하여 URI 뒤의 콘텐츠의 신뢰성과 신뢰도를 평가하고, 리디렉션 URI 및 기타 클라이언트 데이터의 출처를 고려할 수 있다.¶

권한 부여 서버는 리디렉션 URI를 신뢰하는 경우에만 사용자 에이전트를 자동으로 리디렉션해야 한다. URI가 신뢰되지 않는 경우, 권한 부여 서버는 사용자에게 알리고 사용자가 올바른 결정을 내리도록 의존할 수 있다.¶

7.14.1. 발급자 식별을 통한 Mix-Up 방어

이 방어는 권한 부여 서버가 자신의 발급자 식별자를 권한 부여 응답에서 클라이언트에 보내도록 요구한다. 권한 부여 응답을 받을 때, 클라이언트는 받은 발급자 식별자를 저장된 발급자 식별자와 비교해야 한다. 불일치가 있으면 클라이언트는 상호작용을 중단해야 한다.¶

이 발급자 식별자를 클라이언트로 전달하는 방법은 여러 가지가 있다:¶

• 발급자 정보는 예를 들어 선택적 응답 매개변수 iss를 통해 전달될 수 있다 (Section 4.1.2 참조).¶

• OpenID Connect가 사용되고 ID Token이 권한 부여 응답에서 반환되는 경우, 클라이언트는 ID Token의 iss 클레임을 평가할 수 있다.¶

두 경우 모두, iss 값은 [RFC9207]에 따라 평가되어야 한다.¶

이 방어는 발급자 정보를 전달하기 위해 추가 매개변수 사용을 요구할 수 있지만, mix-up에 대한 견고하고 비교적 간단한 방어이다.¶

7.14.2. 구별된 리디렉션 URI를 통한 Mix-Up 방어

이 방어에서 클라이언트는 상호작용하는 각 발급자마다 구별된 리디렉션 URI를 사용해야 한다.¶

클라이언트는 발급자에 대한 구별된 리디렉션 URI를 권한 부여 응답이 수신된 URI와 비교하여 권한 부여 응답이 올바른 발급자로부터 수신되었는지 확인해야 한다. 불일치가 있으면 클라이언트는 흐름을 중단해야 한다.¶

이 방어는 기존 OAuth 기능을 기반으로 하지만, 여러 다른 발급자를 사용하기 위해 클라이언트가 한 번만 등록하는 시나리오(일부 오픈뱅킹 스킴과 같은 경우)에서는 사용할 수 없고, 클라이언트 등록과 긴밀하게 통합되어 있어 자동으로 배포하기가 더 어렵다.¶

또한 공격자는 클라이언트가 공격자의 AS에 할당한 리디렉션 URI를 사용하여 "정직한" AS에 새 클라이언트를 등록함으로써 이 방어가 제공하는 보호를 우회할 수 있을지도 모른다. 그런 다음 공격자는 위에서 설명한 대로 공격을 실행하면서, 클라이언트 ID를 새로 만든 클라이언트의 클라이언트 ID로 바꿀 수 있다.¶

따라서 이 방어는 다른 옵션을 사용할 수 없는 경우에만 사용해야 한다.¶

8.1.1. 네이티브 앱 클라이언트 등록

인스턴스별 자격 증명을 프로비저닝하기 위해 Dynamic Client Registration [RFC7591] 같은 메커니즘을 사용하는 경우를 제외하고, 네이티브 앱은 Section 2.1에 정의된 공개 클라이언트로 분류되며, 권한 부여 서버에 그렇게 등록되어야 한다. 권한 부여 서버는 요청을 그에 맞게 식별하고 처리할 수 있도록 클라이언트 등록 세부 정보에 클라이언트 유형을 기록해야 한다.¶

8.1.2. 네이티브 앱 증명

초안 명세 [I-D.ietf-oauth-attestation-based-client-auth]는 네이티브 앱이 권한 부여 서버 또는 리소스 서버에 인증하기 위해 키에 바인딩된 증명을 얻는 데 사용할 수 있는 메커니즘을 정의한다. 이는 모바일 앱 신원에 대해 더 높은 수준의 보증을 제공할 수 있다.¶

8.4.1. 소유권이 주장된 "https" 스킴 URI 리디렉션

일부 운영 체제, 특히 모바일 운영 체제는 앱이 자신이 제어하는 도메인에서 https URI (Section 4.2.2 of [RFC9110] 참조)의 소유권을 주장하도록 허용한다. 브라우저가 소유권이 주장된 URI를 만나면, 페이지가 브라우저에 로드되는 대신 네이티브 앱이 시작되고 URI가 시작 매개변수로 제공된다.¶

그러한 URI는 네이티브 앱에서 리디렉션 URI로 사용할 수 있다. 권한 부여 서버 입장에서는 일반 웹 기반 클라이언트 리디렉션 URI와 구별되지 않는다. 예는 다음과 같다:¶

https://app.example.com/oauth2redirect/example-provider

리디렉션 URI만으로는 공개 네이티브 앱 클라이언트와 기밀 웹 클라이언트를 구별하기에 충분하지 않으므로, Section 8.1.1에서는 서버가 클라이언트 유형을 결정하고 그에 따라 동작할 수 있도록 클라이언트 등록 중 클라이언트 유형을 기록하는 것을 REQUIRED로 한다.¶

앱이 소유권을 주장한 https 스킴 리디렉션 URI는 다른 네이티브 앱 리디렉션 옵션과 비교할 때, 운영 체제가 대상 앱의 신원을 권한 부여 서버에 보장한다는 장점이 있다. 이러한 이유로 네이티브 앱은 가능한 경우 다른 옵션보다 이를 사용하는 것이 좋다.¶

8.4.2. 루프백 인터페이스 리디렉션

특별한 권한 없이 루프백 네트워크 인터페이스에서 포트를 열 수 있는 네이티브 앱(일반적으로 데스크톱 운영 체제의 앱)은 루프백 인터페이스를 사용하여 OAuth 리디렉션을 수신할 수 있다.¶

루프백 리디렉션 URI는 http 스킴을 사용하며, 루프백 IP 리터럴과 클라이언트가 수신 대기 중인 포트로 구성된다.¶

즉, IPv4의 경우 http://127.0.0.1:{port}/{path}, IPv6의 경우 http://[::1]:{port}/{path}이다. 임의로 할당된 포트와 IPv4 루프백 인터페이스를 사용하는 리디렉션 예는 다음과 같다:¶

http://127.0.0.1:51004/oauth2redirect/example-provider

임의로 할당된 포트와 IPv6 루프백 인터페이스를 사용하는 리디렉션 예는 다음과 같다:¶

http://[::1]:61023/oauth2redirect/example-provider

localhost라는 이름을 사용하는 리디렉션 URI (즉, http://localhost:{port}/{path})도 루프백 IP 리디렉션과 유사하게 동작하지만, localhost 사용은 권장되지 않는다. 리디렉션 URI에 localhost 대신 루프백 IP 리터럴을 지정하면 루프백 인터페이스가 아닌 네트워크 인터페이스에서 의도치 않게 수신 대기하는 일을 피할 수 있다. 또한 사용자 장치의 클라이언트 측 방화벽 및 잘못 구성된 호스트 이름 해석에 덜 취약하다.¶

권한 부여 서버는 요청 시점에 루프백 IP 리디렉션 URI에 임의의 포트가 지정되는 것을 허용해야 한다. 이는 요청 시점에 운영 체제에서 사용 가능한 임시 포트를 얻는 클라이언트를 수용하기 위한 것이다.¶

클라이언트는 장치가 특정 버전의 인터넷 프로토콜을 지원한다고 가정해서는 안 된다. 클라이언트가 IPv4와 IPv6 모두를 사용하여 루프백 인터페이스에 바인딩을 시도하고, 사용 가능한 것을 사용하는 것이 권장된다.¶

8.4.3. 사설 사용 URI 스킴 리디렉션

많은 모바일 및 데스크톱 컴퓨팅 플랫폼은 앱이 com.example.app 같은 사설 사용 URI 스킴(구어적으로 "사용자 지정 URL 스킴"이라고도 함)을 등록하도록 허용함으로써 URI를 통한 앱 간 통신을 지원한다. 브라우저나 다른 앱이 사설 사용 URI 스킴이 있는 URI를 로드하려고 하면, 이를 등록한 앱이 요청을 처리하기 위해 시작된다.¶

사설 사용 URI 스킴을 지원하는 많은 환경은 어떤 스킴의 소유권을 주장하고 다른 당사자가 다른 애플리케이션의 스킴을 사용하는 것을 방지하는 메커니즘을 제공하지 않는다. 따라서 사설 사용 URI 스킴을 사용하는 클라이언트는 리디렉션 URI에 대한 잠재적 공격에 취약하므로, 앞서 언급한 더 안전한 옵션을 사용할 수 없는 경우에만 이 옵션을 사용해야 한다.¶

사설 사용 URI 스킴 리디렉션으로 권한 부여 요청을 수행하려면, 네이티브 앱은 표준 권한 부여 요청으로 브라우저를 실행하지만, 이때 리디렉션 URI는 운영 체제에 등록한 사설 사용 URI 스킴을 사용한다.¶

앱과 연결할 URI 스킴을 선택할 때, 앱은 사설 사용 URI 스킴에 대해 Section 3.8 of [RFC7595]에서 권장한 대로, 자신이 제어하는 도메인 이름을 역순으로 표현한 URI 스킴을 사용해야 한다.¶

예를 들어 app.example.com 도메인 이름을 제어하는 앱은 com.example.app을 스킴으로 사용할 수 있다. 일부 권한 부여 서버는 도메인 이름을 기반으로 클라이언트 식별자를 할당한다. 예를 들어 client1234.usercontent.example.net은 같은 방식으로 역순으로 표현하여 스킴의 도메인 이름으로도 사용할 수 있다. 그러나 myapp 같은 스킴은 도메인 이름을 기반으로 하지 않으므로 이 요구사항을 충족하지 않는다.¶

같은 게시자의 앱이 여러 개 있는 경우, 각 스킴이 그 그룹 안에서 고유하도록 주의해야 한다. 역순 도메인 이름 기반 앱 식별자를 사용하는 플랫폼에서는, 이러한 식별자를 OAuth 리디렉션을 위한 사설 사용 URI 스킴으로 재사용하여 이 문제를 피하는 데 도움을 줄 수 있다.¶

Section 3.2 of [RFC3986]의 요구사항에 따라, 사설 사용 URI 스킴 리디렉션에는 명명 기관이 없으므로 스킴 구성 요소 뒤에는 단일 슬래시(/)만 나타난다. 사설 사용 URI 스킴을 활용하는 완전한 리디렉션 URI 예는 다음과 같다:¶

com.example.app:/oauth2redirect/example-provider

권한 부여 서버가 요청을 완료하면, 평소처럼 클라이언트의 리디렉션 URI로 리디렉션한다. 리디렉션 URI가 사설 사용 URI 스킴을 사용하므로, 그 결과 운영 체제가 네이티브 앱을 실행하고 URI를 시작 매개변수로 전달한다. 그런 다음 네이티브 앱은 권한 부여 응답에 대해 일반 처리를 사용한다.¶

8.5.1. 네이티브 앱의 내장 사용자 에이전트

내장 사용자 에이전트는 네이티브 앱을 권한 부여하기 위한 기술적으로 가능한 방법이다. 이러한 내장 사용자 에이전트는 정의상 권한 부여 서버의 제3자 사용에 안전하지 않다. 내장 사용자 에이전트를 호스팅하는 앱이 앱을 위해 의도된 OAuth 권한 부여 그랜트뿐 아니라 사용자의 전체 인증 자격 증명에도 접근할 수 있기 때문이다. 또한 일반적으로 운영 체제에 의해 샌드박스화되며, 웹 출처에 의존하는 WebAuthn 같은 메커니즘은 비활성화된다.¶

웹뷰 기반 내장 사용자 에이전트의 일반적인 구현에서, 호스트 애플리케이션은 로그인 양식에 입력되는 모든 키 입력을 기록하여 사용자 이름과 비밀번호를 캡처하고, 사용자 동의를 우회하기 위해 자동으로 양식을 제출하며, 세션 쿠키를 복사하여 사용자로 인증된 동작을 수행하는 데 사용할 수 있다.¶

권한 부여 서버와 같은 당사자에 속한 신뢰할 수 있는 앱이 사용하는 경우에도, 내장 사용자 에이전트는 필요한 것보다 더 강력한 자격 증명에 접근하게 되어 최소 권한 원칙을 위반하며, 잠재적으로 공격 표면을 증가시킨다.¶

브라우저가 갖는 일반적인 주소 표시줄과 보이는 인증서 검증 기능 없이 내장 사용자 에이전트에 자격 증명을 입력하도록 사용자를 유도하면, 사용자는 자신이 합법적인 사이트에 로그인하고 있는지 알 수 없다. 실제로 합법적인 사이트라 하더라도, 이는 사용자가 먼저 사이트를 검증하지 않고 자격 증명을 입력해도 괜찮다고 학습하게 만든다.¶

보안 우려와 별개로, 내장 사용자 에이전트는 다른 앱이나 브라우저와 인증 상태를 공유하지 않으므로, 사용자가 모든 권한 부여 요청마다 로그인해야 하며, 이는 종종 열등한 사용자 경험으로 간주된다.¶

8.5.2. 네이티브 앱의 가짜 외부 사용자 에이전트

권한 부여 요청을 시작하는 네이티브 앱은 사용자 인터페이스에 대해 큰 제어권을 가지고 있으며, 잠재적으로 가짜 외부 사용자 에이전트, 즉 외부 사용자 에이전트처럼 보이도록 만든 내장 사용자 에이전트를 표시할 수 있다.¶

모든 선의의 행위자가 외부 사용자 에이전트를 사용할 때의 장점은, 외부 사용자 에이전트를 위조하는 사람은 입증 가능하게 악의적이므로 보안 전문가가 악의적 행위자를 탐지할 수 있다는 것이다. 반면 선의의 행위자와 악의적 행위자 모두가 내장 사용자 에이전트를 사용한다면, 악의적 행위자는 아무것도 위조할 필요가 없어 탐지가 더 어려워진다. 악성 앱이 탐지되면, 이 지식을 사용하여 악성 코드 검사 소프트웨어에서 앱의 서명을 블랙리스트에 올리거나, 앱 스토어에서 배포되는 앱의 경우 제거 조치를 취하고, 악성 앱의 영향과 확산을 줄이기 위한 다른 조치를 취할 수 있다.¶

권한 부여 서버는 진짜 외부 사용자 에이전트에서만 사용할 수 있는 인증 요소를 요구함으로써 가짜 외부 사용자 에이전트에 직접적으로도 보호할 수 있다.¶

인앱 브라우저 탭을 사용할 때 보안에 특히 우려가 있는 사용자는, 인앱 브라우저 탭에서 전체 브라우저로 요청을 열고 그곳에서 권한 부여를 완료하는 추가 조치를 취할 수도 있다. 대부분의 인앱 브라우저 탭 패턴 구현이 그러한 기능을 제공하기 때문이다.¶

8.5.3. 네이티브 앱의 악의적인 외부 사용자 에이전트

악성 앱이 운영 체제에서 https 스킴 URI의 기본 핸들러로 자신을 구성할 수 있다면, 기본 브라우저를 사용하는 권한 부여 요청을 가로채고 이 신뢰 위치를 악용하여 사용자를 피싱하는 등 악의적인 목적을 달성할 수 있다.¶

이 공격은 OAuth에 국한되지 않는다. 이러한 방식으로 구성된 악성 앱은 네이티브 앱의 OAuth 사용을 넘어 사용자에게 일반적이고 지속적인 위험을 제시한다. 많은 운영 체제는 http 및 https 스킴 URI의 기본 핸들러를 변경하려면 명시적인 사용자 동작을 요구함으로써 이 문제를 완화한다.¶

8.5.4. 네이티브 앱의 루프백 리디렉션 고려사항

루프백 인터페이스 리디렉션 URI는 http 스킴(즉, TLS 없이)을 사용할 수 있다. 이는 HTTP 요청이 장치를 벗어나지 않기 때문에 루프백 인터페이스 리디렉션 URI에 허용된다.¶

클라이언트는 권한 부여 요청을 시작할 때만 네트워크 포트를 열고, 응답이 반환되면 포트를 닫는 것이 좋다.¶

클라이언트는 다른 네트워크 행위자의 간섭을 피하기 위해 루프백 네트워크 인터페이스에서만 수신 대기하는 것이 좋다.¶

클라이언트는 Section 8.4.2에 설명된 대로 문자열 localhost보다 루프백 IP 리터럴을 사용하는 것이 좋다.¶