OAuth 2.1 권한 부여 프레임워크

1.3.1. 권한 부여 코드

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

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

권한 부여 코드는 클라이언트를 인증할 수 있는 기능과 액세스 토큰을 리소스 소유자의 사용자 에이전트를 통과시키지 않고 클라이언트에 직접 전송하여 리소스 소유자를 포함한 다른 사람에게 노출될 가능성을 줄이는 등 몇 가지 중요한 보안 이점을 제공합니다.¶

1.3.2. 갱신 토큰

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

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

+--------+                                           +---------------+
|        |--(1)------- 권한 부여 ------------------->|               |
|        |                                           |               |
|        |<-(2)----------- 액세스 토큰 --------------|               |
|        |               & 갱신 토큰                 |               |
|        |                                           |               |
|        |                            +----------+   |               |
|        |--(3)---- 액세스 토큰 ----->|          |   |               |
|        |                            |          |   |               |
|        |<-(4)- 보호된 리소스 -------| 리소스    |   | 권한 부여     |
| 클라이언트|                           |  서버     |   |     서버      |
|        |--(5)---- 액세스 토큰 ----->|          |   |               |
|        |                            |          |   |               |
|        |<-(6)- 유효하지 않은 토큰 오류|          |   |               |
|        |                            +----------+   |               |
|        |                                           |               |
|        |--(7)----------- 갱신 토큰 --------------->|               |
|        |                                           |               |
|        |<-(8)----------- 액세스 토큰 --------------|               |
+--------+           & 선택적 갱신 토큰              +---------------+

그림 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. 액세스 토큰 범위

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

예를 들어 클라이언트는 사용자의 리소스에 대해 "읽기" 접근만 필요하고 리소스를 업데이트할 필요는 없을 수 있으므로, 클라이언트는 권한 부여 서버가 정의한 읽기 전용 범위를 요청하고 리소스 업데이트에 사용할 수 없는 액세스 토큰을 얻을 수 있습니다. 이를 위해서는 권한 부여 서버, 리소스 서버 및 클라이언트 간의 조율이 필요합니다. 권한 부여 서버는 클라이언트가 특정 범위를 요청할 수 있게 하고, 해당 범위를 클라이언트에 발급된 액세스 토큰과 연결합니다. 그러면 리소스 서버는 제한된 범위의 액세스 토큰이 제시될 때 범위를 적용할 책임이 있습니다.¶

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

제한된 범위의 액세스 토큰을 요청하려면 클라이언트는 사용 중인 권한 부여 유형에 따라 권한 부여 또는 토큰 엔드포인트에서 scope 요청 매개변수를 사용합니다. 이에 따라 권한 부여 서버는 scope 응답 매개변수를 사용하여 발급된 액세스 토큰의 범위를 클라이언트에 알립니다.¶

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

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

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

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

1.4.2. Bearer 토큰

Bearer 토큰은 토큰을 보유한 모든 당사자("bearer")가 해당 토큰을 보유한 다른 당사자가 사용할 수 있는 모든 방식으로 토큰을 사용할 수 있다는 속성을 가진 보안 토큰입니다. Bearer 토큰을 사용하기 위해 bearer가 암호화 키 자료의 소유를 증명할 필요는 없습니다(소유 증명).¶

Bearer 토큰은 DPoP [RFC9449] 및 mTLS [RFC8705]와 같은 소유 증명 명세를 사용하여 소유 증명 특성을 제공하도록 강화할 수 있습니다.¶

액세스 토큰 공개를 방지하기 위해 클라이언트와 리소스 서버 간의 통신 상호작용은 1.5절에 설명된 대로 기밀성 및 무결성 보호를 사용해야 합니다.¶

Bearer 토큰의 특정 구조나 형식에 대한 요구 사항은 없습니다. Bearer 토큰이 권한 정보에 대한 참조인 경우, 그러한 참조는 충분히 긴 암호학적으로 무작위인 문자열을 사용하는 등 공격자가 추측할 수 없어야 합니다. Bearer 토큰이 인코딩 메커니즘을 사용하여 권한 정보를 토큰 자체에 포함하는 경우 액세스 토큰은 토큰이 수정되는 것을 방지하기에 충분한 무결성 보호를 사용해야 합니다. 액세스 토큰용 인코딩 및 서명 메커니즘의 한 예는 액세스 토큰용 JSON 웹 토큰 프로파일 [RFC9068]에 설명되어 있습니다.¶

1.4.3. 송신자 제한 액세스 토큰

송신자 제한 액세스 토큰은 액세스 토큰의 사용을 특정 송신자에 결부합니다. 이 송신자는 수신자(예: 리소스 서버)가 해당 액세스 토큰을 수락하기 위한 전제 조건으로 특정 비밀에 대한 지식을 증명해야 합니다.¶

권한 부여 서버와 리소스 서버는 OAuth 소유 증명(DPoP) [RFC9449] 또는 OAuth 2.0용 상호 TLS [RFC8705]와 같은 송신자 제한 액세스 토큰 메커니즘을 사용해야 합니다. 도난되거나 유출된 액세스 토큰의 오용을 방지하려면 4.10.1절의 [RFC9700]을 참조하십시오.¶

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

1.7.1. 값 크기

이 명세는 client_id, 권한 부여 코드, 액세스 토큰, 갱신 토큰 또는 대부분의 다른 프로토콜 매개변수에 대한 최대 길이를 정의하지 않습니다. 이러한 값의 길이는 이를 발급하는 당사자가 선택한 구현 방식에 따라 달라지기 때문입니다. 실제로 구현은 자체 제한을 적용하며, 수신 구현의 제한을 초과하는 값은 요청 실패를 초래합니다.¶

구현은 수신한 값이 특정 길이 안에 들어간다고 가정해서는 안 됩니다. 값을 발급하는 당사자는 그 길이를 문서화해야 하며, 이를 전달할 구성 요소의 제한을 고려해야 합니다. 특히 권한 부여 코드와 같이 리디렉션에서 반환되는 값은 URI 쿼리 문자열로 전달되며, HTTP 구현은 일반적으로 요청 라인과 개별 헤더 필드의 길이를 제한합니다(3절 의 [RFC9112] 및 5.4절 의 [RFC9110]). 구현은 요청이 3절 의 [RFC9112]에서 권장하는 8000옥텟 요청 라인 길이 내에 유지될 수 있을 만큼 긴 매개변수 값을 지원해야 합니다. 특히 리소스 서버는 액세스 토큰 길이에 지나치게 작은 제한을 두어서는 안 됩니다. [RFC9068]에 정의된 것과 같은 구조화된 형식의 토큰은 일반적으로 1킬로바이트를 초과합니다.¶

2.3.1. 등록 요구 사항

권한 부여 서버는 클라이언트가 전체 리디렉션 URI(경로 구성 요소 포함)를 등록하도록 요구해야 합니다. 권한 부여 서버는 등록된 URI와 정확히 일치하지 않는 리디렉션 URI를 지정하는 권한 부여 요청을 거부해야 합니다. 다만 루프백 리디렉션의 경우 포트 URI 구성 요소를 제외하고 정확히 일치해야 합니다. 자세한 내용은 4.1.1절을 참조하십시오.¶

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

등록은 권한 부여 서버에서 클라이언트 정보를 수동으로 구성하는 단계와 같이 대역 외에서 이루어질 수도 있고, 푸시된 권한 부여 요청 [RFC9126]의 초기 POST와 같이 런타임에 이루어질 수도 있습니다.¶

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

충돌 저항 특성에 더하여, 두 앱이 동일한 개인용 URI 스킴을 주장하는 분쟁이 발생한 경우 이는 소유권을 입증하는 데 도움이 될 수 있습니다(한 앱이 악의적으로 동작하는 경우). 예를 들어 두 앱이 com.example.app을 주장한다면, example.com 소유자는 앱 스토어 운영자에게 위조 앱을 제거해 달라고 청원할 수 있습니다. 일반적인 URI 스킴을 사용했다면 이러한 청원은 입증하기 더 어렵습니다.¶

클라이언트는 7.13절에 설명된 것처럼 쿼리 매개변수에서 얻은 임의의 URI로 사용자의 브라우저를 전달하는 URL("오픈 리디렉터")을 노출해서는 안 됩니다. 오픈 리디렉터는 권한 부여 코드와 액세스 토큰의 유출을 가능하게 할 수 있습니다.¶

클라이언트는 필요할 경우 요청별 사용자 정의를 위해 리디렉션 URI를 요청마다 변경하는 대신 state 요청 매개변수를 사용할 수 있습니다.¶

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

2.3.2. 여러 리디렉션 URI

클라이언트에 여러 리디렉션 URI가 등록되어 있는 경우 클라이언트는 redirect_uri 요청 매개변수(4.1.1절)를 사용하여 권한 부여 요청에 리디렉션 URI를 포함해야 합니다. 클라이언트에 하나의 리디렉션 URI만 등록되어 있는 경우 redirect_uri 요청 매개변수는 선택 사항입니다.¶

2.3.3. CSRF 공격 방지

클라이언트는 교차 사이트 요청 위조(CSRF) 공격을 방지해야 합니다. 이 맥락에서 CSRF는 권한 부여 서버가 아니라 악의적인 제3자로부터 발생한 리디렉션 엔드포인트에 대한 요청을 의미합니다 (자세한 내용은 4.4.1.8절의 [RFC6819] 참조). 권한 부여 서버가 code_challenge 매개변수를 지원함을 확인한 클라이언트는 해당 메커니즘이 제공하는 CSRF 보호에 의존할 수 있습니다. OpenID Connect 흐름에서는 nonce 매개변수를 검증하면 CSRF 보호가 제공됩니다. 그 외에는 사용자 에이전트에 안전하게 결부된 state 매개변수로 전달되는 일회용 CSRF 토큰을 CSRF 보호에 사용해야 합니다 (7.10절 참조).¶

2.3.4. Mix-Up 공격 방지

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

Mix-Up 공격에 대한 두 가지 서로 다른 방어의 자세한 설명은 7.15절을 참조하십시오.¶

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":

필수입니다. 2.2절에 설명된 등록 과정에서 클라이언트에 발급된 클라이언트 식별자입니다.¶

"client_secret":

필수입니다. 클라이언트 시크릿입니다.¶

매개변수는 요청 콘텐츠에서만 전송할 수 있으며 요청 URI에 포함해서는 안 됩니다.¶

이는 2절의 [RFC7591]에 정의된 client_secret_post라고도 합니다.¶

예를 들어 콘텐츠 매개변수를 사용하여 액세스 토큰을 갱신하는 요청(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 인증 스킴을 지원할 수 있습니다.¶

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

이는 2절의 [RFC7591]에 정의된 client_secret_basic이라고도 합니다.¶

예를 들면 다음과 같습니다(표시 목적으로만 추가 줄바꿈을 사용함).¶

Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

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

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

2.4.2. 기타 인증 방법

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

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

3.2.1. 클라이언트 인증

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

클라이언트 인증은 다음에 사용됩니다.¶

• 갱신 토큰과 권한 부여 코드를 발급 대상 클라이언트에 결부하는 것을 적용합니다. 권한 부여 코드가 안전하지 않은 채널을 통해 리디렉션 엔드포인트로 전송될 때 클라이언트 인증은 추가 보안 계층을 제공합니다.¶

• 클라이언트를 비활성화하거나 자격 증명을 변경하여 침해된 클라이언트에서 복구하고, 공격자가 도난된 갱신 토큰을 악용하지 못하게 합니다. 하나의 클라이언트 자격 증명 집합을 변경하는 것은 전체 갱신 토큰 집합을 취소하는 것보다 훨씬 빠릅니다.¶

• 주기적인 자격 증명 교체를 요구하는 인증 관리 최선 관행을 구현합니다. 전체 갱신 토큰 집합의 교체는 어려울 수 있지만, 하나의 클라이언트 자격 증명 집합을 교체하는 것은 훨씬 쉽습니다.¶

3.2.2. 토큰 엔드포인트 요청

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

"grant_type":

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

"client_id":

선택 사항입니다. 해당 매개변수에 의존하는 형태의 클라이언트 인증을 사용하거나 grant_type에서 공개 클라이언트 식별을 요구하는 경우 클라이언트 식별자가 필요합니다.¶

기밀 클라이언트는 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. 토큰 엔드포인트 응답

액세스 토큰 요청이 유효하고 권한이 부여된 경우 권한 부여 서버는 액세스 토큰과 선택적 갱신 토큰을 발급합니다.¶

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

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

"access_token":

필수입니다. 권한 부여 서버가 발급한 액세스 토큰입니다.¶

"token_type":

필수입니다. 1.4절에 설명된 발급된 액세스 토큰의 유형입니다. 값은 대소문자를 구분하지 않습니다.¶

"expires_in":

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

"scope":

클라이언트가 요청한 범위와 동일한 경우 권장되며, 그렇지 않은 경우 필수입니다. 1.4.1절에 설명된 액세스 토큰의 범위입니다.¶

"refresh_token":

선택 사항입니다. 해당 토큰 요청에서 전달된 권한 부여를 기반으로 새 액세스 토큰을 얻는 데 사용할 수 있는 갱신 토큰입니다.¶

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

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

매개변수는 부록 C.3에 설명된 대로 JavaScript 객체 표기법(JSON) 구조로 직렬화됩니다.¶

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

예를 들면 다음과 같습니다.¶

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"
}

클라이언트는 응답에서 인식하지 못하는 값 이름을 무시해야 합니다. 권한 부여 서버에서 받은 토큰 및 기타 값의 길이는 1.7.1절에 설명된 대로 정의하지 않습니다.¶

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

권한 부여 서버는 별도로 지정되지 않는 한 HTTP 400 (Bad Request) 상태 코드로 응답하고 다음 매개변수를 응답에 포함합니다.¶

"error":

필수입니다. 다음 중 하나의 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":

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

"error_uri":

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

매개변수는 부록 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 공격으로부터 보호하기 위해 각 권한 부여 요청마다 "코드 검증자"라는 고유한 비밀 값을 사용합니다. 클라이언트는 먼저 코드 검증자를 생성한 다음 권한 부여 요청에 포함할 "코드 챌린지"를 파생합니다. 클라이언트는 토큰 엔드포인트에서 권한 부여 코드를 교환할 때 코드 검증자를 사용하여 권한 부여 코드를 사용하는 클라이언트가 이를 요청한 클라이언트와 동일함을 증명합니다.¶

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

"response_type":

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

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

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

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

"client_id":

필수입니다. 2.2절에 설명된 클라이언트 식별자입니다.¶

"code_challenge":

7.5.1절의 특정 요구 사항이 충족되지 않는 한 필수입니다. 코드 검증자에서 파생된 코드 챌린지입니다.¶

"code_challenge_method":

필수이며, 값은 S256 또는 향후 확장에서 정의하는 값입니다.¶

"redirect_uri":

이 클라이언트에 하나의 리디렉션 URI만 등록된 경우 선택 사항입니다. 이 클라이언트에 여러 리디렉션 URI가 등록된 경우 필수입니다. 2.3.2절을 참조하십시오.¶

"scope":

선택 사항입니다. 1.4.1절에 설명된 접근 요청의 범위입니다.¶

"state":

선택 사항입니다. 클라이언트가 요청과 콜백 사이의 상태를 유지하기 위해 사용하는 불투명한 값입니다. 권한 부여 서버는 사용자 에이전트를 클라이언트로 다시 리디렉션할 때 이 값을 포함합니다. 이 값은 권한 부여 요청 URI의 쿼리 구성 요소와 다시 클라이언트로 돌아가는 리디렉션에 포함되므로, 실제 길이는 권한 부여 서버, 사용자 에이전트 및 클라이언트가 허용하는 URI와 HTTP 헤더 필드 길이에 의해 제한됩니다. 1.7.1절을 참조하십시오.¶

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)))

이 명세는 S256 변환만 정의합니다. 향후 확장에서 추가 변환 방법을 정의할 수 있습니다.¶

code_challenge의 ABNF는 다음과 같습니다.¶

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

code_challenge와 code_verifier 속성은 원래 이 기법이 개발된 "코드 교환용 증명 키", 즉 PKCE [RFC7636]로 알려진 OAuth 2.0 확장에서 채택되었습니다. [RFC7636]에 정의된 plain 변환 방법은 이 명세에서 제거되었으며 명시적으로 금지됩니다. 자세한 내용은 7.5.2절을 참조하십시오.¶

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

클라이언트는 code_challenge와 code_verifier를 사용해야 하며, 권한 부여 서버는 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가 있는 경우 이를 검증하여, 클라이언트 등록 중 미리 설정한 등록된 리디렉션 URI 중 하나와 일치하는지 확인해야 합니다(2절). 두 URI를 비교할 때 권한 부여 서버는 두 URI가 동일한지 확인해야 합니다. 자세한 내용은 6.2.1절의 [RFC3986]에 있는 단순 문자열 비교를 참조하십시오. 유일한 예외는 localhost URI를 사용하는 네이티브 앱입니다. 이 경우 권한 부여 서버는 8.4.2절에 설명된 대로 가변 포트 번호를 허용해야 합니다.¶

요청이 유효하면 권한 부여 서버는 리소스 소유자를 인증하고 권한 부여 결정을 얻습니다(리소스 소유자에게 묻거나 다른 수단을 통해 승인을 설정함).¶

결정이 이루어지면 권한 부여 서버는 HTTP 리디렉션 응답 또는 사용자 에이전트를 통해 사용할 수 있는 다른 수단을 사용하여 사용자 에이전트를 제공된 클라이언트 리디렉션 URI로 보냅니다.¶

4.1.2. 권한 부여 응답

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

"code":

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

"state":

클라이언트 권한 부여 요청에 state 매개변수가 존재한 경우 필수입니다. 클라이언트에서 받은 정확한 값입니다.¶

"iss":

필수입니다. 클라이언트가 둘 이상의 권한 부여 서버와 상호작용하는 경우 Mix-Up 공격을 방지하기 위해 사용할 수 있는 권한 부여 서버의 발급자 식별자입니다. 클라이언트가 이를 사용해 Mix-Up 공격을 방지하는 방법에 대한 자세한 내용은 7.15절 및 [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

클라이언트는 인식하지 못하는 응답 매개변수를 무시해야 합니다. 권한 부여 코드 문자열의 길이는 1.7.1절에 설명된 대로 이 명세에서 정의하지 않습니다.¶

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

서버가 code_challenge를 발급된 코드와 연결하는 정확한 방법은 이 명세의 범위를 벗어납니다. 코드 챌린지는 서버에 저장하여 코드와 연결할 수 있습니다. code_challenge와 code_challenge_method 값은 코드 자체에 암호화된 형태로 저장할 수도 있지만 서버는 AS 이외의 주체가 추출할 수 있는 형태로 code_challenge 값을 응답 매개변수에 포함해서는 안 됩니다.¶

클라이언트는 공격자가 권한 부여 코드를 권한 부여 응답에 주입(재생)하지 못하도록 해야 합니다. code_challenge와 code_verifier를 사용하면 권한 부여 서버가 일치하지 않는 code_verifier가 포함된 토큰 요청을 거부하므로 권한 부여 코드 주입을 방지할 수 있습니다. 자세한 내용은 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로 식별됩니다.¶

이 값이 설정되면 3.2.2절의 매개변수 외에 다음과 같은 추가 토큰 요청 매개변수가 지원됩니다.¶

"code":

필수입니다. 권한 부여 서버에서 받은 권한 부여 코드입니다.¶

"code_verifier":

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

"client_id":

클라이언트가 3.2.1절에 설명된 대로 권한 부여 서버에 인증하지 않는 경우 필수입니다.¶

권한 부여 서버는 주어진 권한 부여 코드에 대해 액세스 토큰을 한 번만 반환해야 합니다.¶

이전에 성공한 토큰 요청과 동일한 권한 부여 코드로 두 번째 유효한 토큰 요청이 이루어진 경우 권한 부여 서버는 요청을 거부해야 하며, 가능하면 해당 권한 부여 코드를 기반으로 이전에 발급된 모든 액세스 토큰과 갱신 토큰을 취소하는 것이 좋습니다. 자세한 내용은 7.5.3절을 참조하십시오.¶

예를 들어 클라이언트는 다음 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

3.2.2절의 처리 규칙에 더하여 권한 부여 서버는 다음을 수행해야 합니다.¶

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

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

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

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

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

토큰 요청의 redirect_uri 매개변수와 관련하여 OAuth 2.0 클라이언트와의 이전 버전 호환성에 대한 자세한 내용은 10.2절을 참조하십시오.¶

4.2.1. 토큰 엔드포인트 확장

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

이 값이 설정되면 3.2.2절의 매개변수 외에 다음 추가 토큰 요청 매개변수가 지원됩니다.¶

"scope":

선택 사항입니다. 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으로 식별됩니다.¶

이 값이 설정되면 3.2.2절의 매개변수 외에 다음 추가 매개변수가 지원됩니다.¶

"refresh_token":

필수입니다. 클라이언트에 발급된 갱신 토큰입니다.¶

"scope":

선택 사항입니다. 1.4.1절에 설명된 접근 요청의 범위입니다. 요청한 범위에는 리소스 소유자가 원래 부여하지 않은 범위가 포함되어서는 안 되며, 생략된 경우 리소스 소유자가 원래 부여한 범위와 동일한 것으로 취급됩니다.¶

갱신 토큰은 일반적으로 추가 액세스 토큰을 요청하는 데 사용되는 장기간의 자격 증명이므로, 갱신 토큰은 이를 발급받은 클라이언트에 결부됩니다. 기밀 클라이언트는 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

3.2.2절의 처리 규칙에 더하여 권한 부여 서버는 다음을 수행해야 합니다.¶

• 요청에 클라이언트 인증이 포함된 경우 갱신 토큰이 인증된 클라이언트에 발급되었는지 확인하고, 또는 요청에 client_id가 포함된 경우 갱신 토큰이 일치하는 클라이언트에 발급되었는지 확인해야 하며¶

• 이 갱신 토큰에 해당하는 권한 부여가 여전히 활성 상태인지 검증해야 하며¶

• 갱신 토큰을 검증해야 합니다.¶

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

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

• 갱신 토큰 교체: 권한 부여 서버는 모든 액세스 토큰 갱신 응답마다 새 갱신 토큰을 발급합니다. 이전 갱신 토큰은 무효화되지만 두 토큰 간 관계에 관한 정보는 권한 부여 서버가 유지합니다. 갱신 토큰이 침해된 후 공격자와 적법한 클라이언트가 모두 이를 사용하는 경우 둘 중 하나가 무효화된 갱신 토큰을 제시하게 되며, 이를 통해 권한 부여 서버가 침해 사실을 알 수 있습니다. 권한 부여 서버는 유효하지 않은 갱신 토큰을 어느 당사자가 제출했는지 확인할 수 없지만, 활성 갱신 토큰과 그에 연결된 접근 권한 부여를 모두 취소합니다. 이는 적법한 클라이언트가 새 권한 부여를 얻도록 강제하는 대가로 공격을 중단합니다.¶

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

4.3.2. 갱신 토큰 응답

유효하고 권한이 부여된 경우 권한 부여 서버는 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 헤더 필드 구문은 2절의 [RFC2617]에 정의된 Basic 스킴 사용을 따릅니다. Basic과 마찬가지로 1.2절의 [RFC2617]에 정의된 일반 구문에는 부합하지 않지만, HTTP 1.1 인증 [RFC7235]의 일반 인증 프레임워크와 호환됩니다. 다만 기존 배포를 반영하기 위해 거기에 설명된 권장 관행을 따르지는 않습니다. Bearer 자격 증명의 구문은 다음과 같습니다.¶

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

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

11.1절의 [RFC9110]에 설명된 대로 문자열 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 요청에 application/x-www-form-urlencoded로 설정된 Content-Type 헤더 필드가 포함되어야 합니다.¶

• 콘텐츠는 URL 현행 표준 [WHATWG.URL]에 정의된 application/x-www-form-urlencoded 콘텐츠 유형의 인코딩 요구 사항을 따라야 합니다.¶

• 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":

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

"scope":

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

다음은 두 가지 범위 값의 예이며, 각각 OpenID Connect [OpenID.Messages] 및 Open Authentication Technology Committee (OATC) 온라인 멀티미디어 권한 부여 프로토콜 [OMAP] OAuth 2.0 사용 사례에서 가져온 것입니다.¶

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

¶

"error":

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

"error_description":

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

"error_uri":

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

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

scope 속성의 값(부록 A.4에 지정됨)은 범위 값을 나타낼 때 %x21 / %x23-5B / %x5D-7E 집합 밖의 문자를 포함해서는 안 되며, 범위 값 사이의 구분자로는 %x20을 사용해야 합니다. error 및 error_description 속성의 값(부록 A.7 및 부록 A.8에 지정됨)은 %x20-21 / %x23-5B / %x5D-7E 집합 밖의 문자를 포함해서는 안 됩니다. error_uri 속성의 값(부록 A.9에 지정됨)은 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 토큰 인증 스킴 간에 공유할 오류 값을 위한 공통 레지스트리를 11.4절의 [RFC6749]에 설정합니다.¶

주로 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 특별 간행물 800-63 [NIST800-63]을 기반으로 합니다.¶

7.1.2. 위협 완화

디지털 서명을 사용하여 액세스 토큰의 내용을 보호하고, 주기적인 키 교체와 같은 서명 키 관리의 최선 관행을 따르면 광범위한 위협을 완화할 수 있습니다.¶

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

이 문서는 액세스 토큰의 인코딩이나 내용을 지정하지 않으므로 액세스 토큰의 무결성 보호를 보장하는 수단에 관한 상세한 권고 사항은 이 명세의 범위를 벗어납니다. 액세스 토큰의 인코딩 및 서명 메커니즘의 한 예는 액세스 토큰용 JSON 웹 토큰 프로파일 [RFC9068]에 설명되어 있습니다.¶

액세스 토큰 리디렉션에 대응하려면 권한 부여 서버가 의도된 수신자의 신원(대상)을, 일반적으로 하나의 리소스 서버 (또는 리소스 서버 목록) 형태로 토큰에 포함하는 것이 중요합니다. 토큰 사용을 특정 범위로 제한하는 것도 권장됩니다.¶

1.5절에서는 액세스 토큰 공개를 방지하고 클라이언트, 리소스 서버 및 권한 부여 서버 간 통신의 기밀성과 무결성을 제공하기 위한 정보를 제공합니다.¶

7.1.3. 권고 사항 요약

7.1.4. 액세스 토큰 권한 제한

액세스 토큰과 연결된 권한은 특정 애플리케이션 또는 사용 사례에 필요한 최소한으로 제한하는 것이 좋습니다. 이렇게 하면 클라이언트가 리소스 소유자가 승인한 권한을 초과하는 것을 방지할 수 있습니다. 또한 사용자가 해당 보안 정책으로 승인된 자신의 권한을 초과하는 것도 방지합니다. 권한 제한은 액세스 토큰 유출의 영향을 줄이는 데에도 도움이 됩니다.¶

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

또한 액세스 토큰은 리소스 서버 또는 리소스의 특정 리소스와 작업으로 제한하는 것이 좋습니다. 이를 적용하기 위해 권한 부여 서버는 액세스 토큰을 해당 리소스 및 작업과 연결하고, 모든 리소스 서버는 모든 요청에서 해당 요청과 함께 전송된 액세스 토큰이 특정 리소스에 대한 특정 작업에 사용하도록 의도된 것인지 검증해야 합니다. 그렇지 않으면 리소스 서버는 해당 요청의 처리를 거부해야 합니다. 클라이언트와 권한 부여 서버는 [RFC9396]에 지정된 scope 및 authorization_details 매개변수를 사용하여 이러한 리소스 및/또는 작업을 결정할 수 있습니다.¶

7.3.1. 네이티브 앱 사칭

위에서 설명한 것처럼 권한 부여 서버는 클라이언트의 신원을 보장할 수 있는 경우를 제외하고 사용자 동의나 상호작용 없이 권한 부여 요청을 자동으로 처리하지 않는 것이 좋습니다. 여기에는 사용자가 특정 클라이언트 ID에 대한 권한 부여 요청을 이전에 승인한 경우도 포함됩니다. 클라이언트의 신원을 증명할 수 없다면 이전 요청이 승인되지 않은 것처럼 요청을 처리하는 것이 좋습니다.¶

선언된 https 스킴 리디렉션과 같은 조치는 권한 부여 서버가 신원 증명으로 허용할 수 있습니다. 일부 운영 체제는 적절한 경우 허용할 수 있는 다른 플랫폼별 신원 기능을 제공할 수도 있습니다.¶

7.3.2. 액세스 토큰 권한 제한

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

액세스 토큰과 연결된 권한은 특정 애플리케이션 또는 사용 사례에 필요한 최소한으로 제한하는 것이 좋습니다. 이렇게 하면 클라이언트가 리소스 소유자가 승인한 권한을 초과하는 것을 방지할 수 있습니다. 또한 사용자가 해당 보안 정책으로 승인된 자신의 권한을 초과하는 것도 방지합니다. 권한 제한은 액세스 토큰 유출의 영향을 줄이는 데에도 도움이 됩니다.¶

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

7.5.1. 권한 부여 코드 주입

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

7.5.2. PKCE "plain" 코드 챌린지 방법

[RFC7636]에 정의된 plain 코드 챌린지 방법은 OAuth 2.1에서 명시적으로 금지됩니다. plain 방법은 코드 검증자가 권한 부여 요청에서 평문으로 전송되므로 권한 부여 요청을 읽을 수 있는 공격자 ([RFC9700]의 공격자 A4)에 의한 권한 부여 코드 가로채기에 대한 보호를 제공하지 않습니다.¶

plain 모드를 지원해야 한다는 역사적 주장 (암호학적 해시 기능이 없는 장치)은 인증서 검증에 SHA-256 지원을 요구하는 OAuth 2.1의 TLS 1.2+ 요구 사항으로 인해 더 이상 유효하지 않습니다. OAuth 2.1을 구현할 수 있는 모든 장치는 필연적으로 SHA-256을 지원합니다.¶

plain 코드 챌린지 방법을 지원하는 권한 부여 서버는 검증할 수 없는 다운그레이드 공격 벡터를 만듭니다. 서버는 적법한 제한 클라이언트와 제한 클라이언트라고 주장하도록 공격자가 수정한 요청을 구분할 수 없기 때문입니다.¶

S256을 지원할 수 없는 기존 클라이언트가 있는 배포에서는 레거시 권한 부여 방법 지원을 중단하기 전에 수명이 연장된 갱신 토큰을 발급하는 것이 좋습니다. 갱신 토큰 부여(4.3절)에는 PKCE가 필요하지 않기 때문입니다.¶

7.5.3. 권한 부여 코드 재사용

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

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

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

7.5.4. HTTP 307 리디렉션

사용자 자격 증명이 포함될 수 있는 요청을 리디렉션하는 권한 부여 서버는 리디렉션에 307 상태 코드 (15.4.8절의 [RFC9110])를 사용해서는 안 됩니다. 이러한 요청에 HTTP 리디렉션(예를 들어 JavaScript가 아닌)을 사용하는 경우 AS는 상태 코드 303("See Other")을 사용하는 것이 좋습니다.¶

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

리디렉션에 상태 코드 307을 사용하면 사용자 에이전트는 POST 요청을 통해 사용자 자격 증명을 클라이언트에 전송하게 됩니다.¶

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

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

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

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

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

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

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

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

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

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

1. 예를 들어 유효하지 않은 범위 값을 사용하여 의도적으로 잘못된 권한 부여 요청을 전송하고, 이를 통해 권한 부여 서버가 사용자 에이전트를 자신의 피싱 사이트로 리디렉션하도록 합니다.¶

2. 공격자가 제어하는 client_id 및 redirect_uri를 사용하여 의도적으로 유효한 권한 부여 요청을 전송합니다. 사용자가 인증한 후 권한 부여 서버는 사용자에게 요청에 대한 동의를 요구합니다. 사용자가 요청에 문제가 있음을 알아차리고 요청을 거부하더라도 권한 부여 서버는 여전히 사용자 에이전트를 피싱 사이트로 리디렉션합니다. 이 경우 사용자가 어떤 조치를 취하더라도 사용자 에이전트는 피싱 사이트로 리디렉션됩니다.¶

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

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

권한 부여 서버는 리디렉션 URI를 신뢰하는 경우에만 사용자 에이전트를 자동으로 리디렉션하는 것이 좋습니다. URI를 신뢰하지 않는 경우 권한 부여 서버는 사용자에게 알리고 사용자가 올바른 결정을 내리도록 맡길 수 있습니다.¶

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

이 방어에서는 클라이언트가 권한 부여 서버가 권한 부여 응답에서 클라이언트에 보내는 발급자 식별자 값을 비교해야 합니다. 권한 부여 응답을 받을 때 클라이언트는 수신한 발급자 식별자를 저장된 발급자 식별자와 비교해야 합니다. 일치하지 않으면 클라이언트는 상호작용을 중단해야 합니다.¶

이 발급자 식별자를 클라이언트에 전달하는 방법에는 여러 가지가 있습니다.¶

• 발급자 정보는 응답 매개변수 iss를 통해 전달됩니다 (4.1.2절 참조).¶

• OpenID Connect를 사용하고 ID 토큰이 권한 부여 응답에 반환되는 경우 클라이언트는 ID 토큰의 iss claim을 평가할 수 있습니다.¶

두 경우 모두 iss 값은 [RFC9207]에 따라 평가해야 합니다.¶

이 방어에서는 발급자 정보를 전달하기 위해 추가 매개변수를 사용해야 할 수 있지만, Mix-Up에 대한 강력하고 비교적 단순한 방어입니다.¶

7.15.2. 서로 다른 리디렉션 URI를 통한 Mix-Up 방어

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

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

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

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

따라서 이 방어는 다른 선택지가 없는 경우에만 사용하는 것이 좋습니다.¶

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

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

8.1.2. 네이티브 앱 증명

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

8.4.1. 선언된 "https" 스킴 URI 리디렉션

일부 운영 체제, 특히 모바일 운영 체제는 앱이 자신이 제어하는 도메인의 https URI를 선언하도록 허용합니다 (4.2.2절의 [RFC9110] 참조). 브라우저가 선언된 URI를 만나면 브라우저에서 페이지를 로드하는 대신 해당 URI를 실행 매개변수로 전달하여 네이티브 앱을 실행합니다.¶

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

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

리디렉션 URI만으로는 공개 네이티브 앱 클라이언트와 기밀 웹 클라이언트를 구분하기에 충분하지 않으므로 8.1.1절에서는 서버가 클라이언트 유형을 확인하여 그에 따라 동작할 수 있도록 클라이언트 등록 중 클라이언트 유형을 기록하도록 요구합니다.¶

앱이 선언한 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 사용은 권장되지 않습니다. localhost 대신 루프백 IP 리터럴을 리디렉션 URI로 지정하면 실수로 루프백 인터페이스가 아닌 네트워크 인터페이스에서 수신 대기하는 일을 피할 수 있습니다. 또한 클라이언트 측 방화벽 및 사용자 장치의 잘못 구성된 호스트 이름 확인에 덜 취약합니다.¶

권한 부여 서버는 요청 시 운영 체제에서 사용 가능한 임시 포트를 얻는 클라이언트를 지원하기 위해 루프백 IP 리디렉션 URI에서 요청 시 어떤 포트든 지정할 수 있도록 허용해야 합니다.¶

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

8.4.3. 개인용 URI 스킴 리디렉션

많은 모바일 및 데스크톱 컴퓨팅 플랫폼은 앱이 com.example.app과 같은 개인용 URI 스킴 (구어적으로 "사용자 정의 URL 스킴"이라고도 함)을 등록하도록 허용하여 URI를 통한 앱 간 통신을 지원합니다. 브라우저 또는 다른 앱이 개인용 URI 스킴을 가진 URI를 로드하려고 하면 이를 등록한 앱이 요청을 처리하기 위해 실행됩니다.¶

개인용 URI 스킴을 지원하는 많은 환경은 하나의 스킴을 독점하고 다른 당사자가 다른 애플리케이션의 스킴을 사용하는 것을 막는 메커니즘을 제공하지 않습니다. 따라서 개인용 URI 스킴을 사용하는 클라이언트는 리디렉션 URI에 대한 잠재적인 공격에 취약하므로, 앞서 언급한 더 안전한 선택지를 사용할 수 없는 경우에만 이 선택지를 사용하는 것이 좋습니다.¶

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

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

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

동일한 게시자가 여러 앱을 제공하는 경우 해당 그룹 내에서 각 스킴이 고유하도록 주의해야 합니다. 역순 도메인 이름을 기반으로 한 앱 식별자를 사용하는 플랫폼에서는 이러한 식별자를 OAuth 리디렉션용 개인용 URI 스킴으로 재사용하여 이 문제를 피할 수 있습니다.¶

3.2절의 [RFC3986] 요구 사항에 따르면 개인용 URI 스킴 리디렉션에는 명명 권한이 없으므로 스킴 구성 요소 뒤에 단일 슬래시(/)만 나타납니다. 개인용 URI 스킴을 사용하는 완전한 리디렉션 URI의 예는 다음과 같습니다.¶

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

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

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

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

일반적인 web-view 기반 내장 사용자 에이전트 구현에서 호스트 애플리케이션은 로그인 폼에 입력되는 모든 키 입력을 기록하여 사용자 이름과 비밀번호를 탈취하고, 사용자 동의를 우회하도록 폼을 자동 제출하며, 세션 쿠키를 복사하여 사용자를 대신한 인증된 작업을 수행할 수 있습니다.¶

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

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

보안 문제 외에도 내장 사용자 에이전트는 다른 앱이나 브라우저와 인증 상태를 공유하지 않으므로 사용자가 모든 권한 부여 요청마다 로그인해야 하며, 이는 일반적으로 더 좋지 않은 사용자 경험으로 간주됩니다.¶

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

권한 부여 요청을 시작하는 네이티브 앱은 사용자 인터페이스를 상당히 제어할 수 있으며 외부 사용자 에이전트처럼 보이도록 만든 내장 사용자 에이전트인 가짜 외부 사용자 에이전트를 표시할 수 있습니다.¶

모든 정상적인 행위자가 외부 사용자 에이전트를 사용할 때의 장점은 보안 전문가가 악의적인 행위자를 탐지할 수 있다는 것입니다. 외부 사용자 에이전트를 위조하는 행위자는 명백하게 악의적임을 입증할 수 있기 때문입니다. 반대로 정상적인 행위자와 악의적인 행위자가 모두 내장 사용자 에이전트를 사용한다면 악의적인 행위자는 아무것도 위조할 필요가 없으므로 탐지가 더 어려워집니다. 악의적인 앱이 탐지되면 이 정보를 이용하여 악성 코드 검사 소프트웨어에서 앱의 서명을 차단 목록에 올리고, 앱 스토어를 통해 배포된 앱의 경우 제거 조치를 취하는 등 악의적인 앱의 영향과 확산을 줄이는 다른 조치를 취할 수 있습니다.¶

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

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

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

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

이 공격은 OAuth에 한정되지 않습니다. 이러한 방식으로 구성된 악의적인 앱은 네이티브 앱의 OAuth 사용을 넘어 사용자에게 일반적이고 지속적인 위험을 초래합니다. 많은 운영 체제는 http 및 https 스킴 URI의 기본 처리기를 변경할 때 명시적인 사용자 작업을 요구하여 이 문제를 완화합니다.¶

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

루프백 인터페이스 리디렉션 URI는 http 스킴(즉, TLS 없이)을 사용할 수 있습니다. HTTP 요청이 장치 밖으로 나가지 않으므로 루프백 인터페이스 리디렉션 URI에서는 이를 허용할 수 있습니다.¶

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

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

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