1.1. 위임과 가장의 의미론

STS의 일반적인 사용 사례(이전 절에서 암시한 것처럼) 중 하나는 리소스 서버 A가 요청 사용자 B를 대신하여 백엔드 서비스 C를 호출할 수 있게 하는 것이다. 로컬 사이트 정책과 인가 인프라에 따라, A가 자신의 자격 증명을 사용해 C에 액세스하면서 A가 B를 대신하여 행동한다는 어떤 형태의 주석("위임")을 함께 두는 것이 바람직할 수도 있고, A에게 C에 대한 제한된 액세스 자격 증명을 부여하되 그 자격 증명이 계속 B를 인가된 엔티티로 식별하게 하는 것("가장")이 바람직할 수도 있다. 위임과 가장은 여러 참여자가 관련된 다른 시나리오에서도 유용한 개념일 수 있다.¶

주체 A가 주체 B를 가장하면, A는 어떤 정의된 권리 맥락 안에서 B가 가진 모든 권리를 부여받으며 그 맥락에서 B와 구별되지 않는다. 따라서 주체 A가 주체 B를 가장하는 경우, 그러한 토큰을 받는 어떤 엔티티의 관점에서도 그들은 실제로 B와 상대하고 있는 것이다. 신원 시스템의 일부 구성원이 가장이 이루어지고 있음을 인지할 수도 있지만, 그것은 요구사항이 아니다. 모든 의도와 목적에서, A가 B를 가장할 때 A는 토큰이 인가한 권리의 맥락 안에서 B이다. A가 B를 가장할 수 있는 능력은 토큰의 내용이나 대역 외 메커니즘을 통해 범위나 시간, 심지어 일회성 사용 제한으로 제한될 수 있다.¶

위임 의미론은 가장 의미론과 다르지만, 둘은 밀접하게 관련되어 있다. 위임 의미론에서는 주체 A가 여전히 B와 별개의 자신의 신원을 가지며, B가 자신의 권리 일부를 A에게 위임했을 수 있지만 수행되는 모든 행위는 B를 대표하는 A에 의해 이루어진다는 점이 명시적으로 이해된다. 어떤 의미에서 A는 B의 대리인이다.¶

위임과 가장이 모든 상황을 포괄하는 것은 아니다. 예를 들어 어떤 주체가 직접 자신을 위해 행동하는 경우, 위임도 가장도 적용되지 않는다. 그러나 이들은 토큰 교환에서 작동하는 더 일반적인 의미론이므로, 이 명세에서 더 직접적으로 다룬다.¶

위임 의미론은 일반적으로 토큰 안에 토큰의 기본 주체와 그 주체가 자신의 일부 권리를 위임한 행위자에 대한 정보를 모두 포함함으로써 표현된다. 그러한 토큰은 여러 주체에 대한 정보로 구성되어 있으므로 복합 토큰이라고 불리기도 한다. 일반적으로 요청에서 subject_token은 토큰이 요청되는 대상 당사자의 신원을 나타내며, actor_token은 발급된 토큰의 액세스 권리가 위임되는 당사자의 신원을 나타낸다. 인가 서버가 발급한 복합 토큰은 두 당사자 모두에 대한 정보를 포함한다. 복합 토큰을 언제, 그리고 발급할지 여부는 인가 서버와 적용 가능한 정책 및 구성의 재량이다.¶

복합 토큰을 표현하는 구체적인 방식과 그러한 토큰이 발급될지 여부조차도 구현의 세부 사항과 토큰의 종류에 따라 달라진다. JWT가 아닌 복합 토큰의 표현은 이 명세의 범위를 벗어난다. 그러나 actor_token 요청 매개변수는 원하는 행위자에 대한 정보를 제공하는 수단을 제공하며, JWT act 클레임은 위임 체인의 표현을 제공할 수 있다.¶

1.2. 요구사항 표기와 규약

이 문서에서 키워드 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"는 여기에 표시된 것처럼 모두 대문자로 나타날 때, 그리고 그 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석된다.¶

1.3. 용어

이 명세는 OAuth 2.0 [RFC6749]에서 정의한 "access token type", "authorization server", "client", "client identifier", "resource server", "token endpoint", "token request", 및 "token response"라는 용어와, JSON Web Token (JWT) [JWT]에서 정의한 "Base64url Encoding", "Claim", 및 "JWT Claims Set"라는 용어를 사용한다.¶

2.1. 요청

클라이언트는 [RFC6749]의 섹션 4.5에 정의된 extension grant type 메커니즘을 사용하여 인가 서버의 토큰 엔드포인트에 토큰 요청을 보냄으로써 보안 토큰을 요청한다.¶

인가 서버에 대한 클라이언트 인증은 OAuth 2.0이 제공하는 일반적인 메커니즘을 사용하여 수행된다. [RFC6749]의 섹션 2.3.1은 클라이언트의 비밀번호 기반 인증을 정의하지만, 클라이언트 인증은 확장 가능하며 다른 메커니즘도 가능하다. 예를 들어, [RFC7523]은 bearer JSON Web Token (JWT) [JWT]을 사용한 클라이언트 인증을 정의한다. 지원되는 클라이언트 인증 방법과 인증되지 않았거나 식별되지 않은 클라이언트를 허용할지 여부는 인가 서버의 재량에 따르는 배포 결정이다. 클라이언트 인증을 생략하면 손상된 토큰을 보유한 누구든지 STS를 통해 그 손상된 토큰을 다른 토큰으로 활용할 수 있다는 점에 유의한다. 따라서 클라이언트 인증은 어떤 엔티티가 다른 엔티티를 가장하거나 다른 엔티티로부터 위임을 받을 수 있는지에 관해 STS가 추가 인가 검사를 수행할 수 있게 한다.¶

클라이언트는 HTTP POST 메서드를 사용하여 extension grant type과 함께 토큰 엔드포인트로 토큰 교환 요청을 보낸다. 다음 매개변수는 [RFC6749]의 부록 B에 설명된 대로 UTF-8 문자 인코딩을 사용한 application/x-www-form-urlencoded 형식으로 HTTP 요청 entity-body에 포함된다.¶

grant_type

REQUIRED. 값 urn:ietf:params:oauth:grant-type:token-exchange는 토큰 교환이 수행되고 있음을 나타낸다.¶

resource

OPTIONAL. 클라이언트가 요청한 보안 토큰을 사용하려는 대상 서비스 또는 리소스를 나타내는 URI이다. 이는 인가 서버가 대상에 맞게 적절한 정책을 적용할 수 있게 한다. 예를 들어 발급할 토큰의 유형과 내용을 결정하거나, 토큰을 암호화할지 여부와 암호화 방법을 결정할 수 있다. 많은 경우 클라이언트는 상호 작용하는 시스템의 논리적 조직을 알지 못하며, 토큰을 사용하려는 서비스의 URI만 알게 된다. resource 매개변수는 클라이언트가 토큰 교환 요청에서 보통 https URL로 위치를 제공함으로써, 해당 리소스에 접근할 때 사용될 것과 동일한 형식으로 발급된 토큰을 어디에서 사용하려는지 인가 서버에 표시할 수 있게 한다. 인가 서버는 일반적으로 resource URI 값에서 적절한 정책으로 매핑하는 기능을 가진다. resource 매개변수의 값은 [RFC3986]의 섹션 4.3에 명시된 절대 URI여야 MUST 하며, 쿼리 구성요소를 포함할 수 MAY 있지만 프래그먼트 구성요소를 포함해서는 MUST NOT 안 된다. 여러 resource 매개변수를 사용하여 발급된 토큰이 나열된 여러 리소스에서 사용될 예정임을 나타낼 수 있다. resource 매개변수에 관한 추가 배경과 사용은 [OAUTH-RESOURCE]를 참조한다.¶

audience

OPTIONAL. 클라이언트가 요청한 보안 토큰을 사용하려는 대상 서비스의 논리적 이름이다. 이는 resource 매개변수와 유사한 목적을 수행하지만, 클라이언트가 대상 서비스에 대한 논리적 이름을 제공한다. 이름의 해석은 그 값이 클라이언트와 인가 서버 모두가 이해하는 것이어야 함을 요구한다. OAuth 클라이언트 식별자, SAML 엔티티 식별자 [OASIS.saml-core-2.0-os], 및 OpenID Connect Issuer Identifier [OpenID.Core]는 audience 매개변수 값으로 사용될 수 있는 것의 예이다. 그러나 주어진 인가 서버와 함께 사용되는 audience 값은 해당 서버 안에서 고유해야 하며, 이는 그것들이 의도한 값 유형으로 올바르게 해석되도록 보장하기 위함이다. 여러 audience 매개변수를 사용하여 발급된 토큰이 나열된 여러 대상에서 사용될 예정임을 나타낼 수 있다. audience와 resource 매개변수를 함께 사용하여 논리적 이름과 리소스 URI가 섞인 여러 대상 서비스를 나타낼 수 있다.¶

scope

OPTIONAL. [RFC6749]의 섹션 3.3에 정의된 대로, 공백으로 구분되고 대소문자를 구분하는 문자열 목록으로, 클라이언트가 토큰이 사용될 서비스 또는 리소스의 맥락에서 요청한 보안 토큰의 원하는 범위를 지정할 수 있게 한다. scope의 값과 관련 의미론은 서비스별로 다르며, 관련 서비스 문서에 설명될 것으로 예상된다.¶

requested_token_type

OPTIONAL. 요청한 보안 토큰의 유형에 대한 섹션 3에 설명된 식별자이다. 요청한 유형이 지정되지 않은 경우, 발급되는 토큰 유형은 인가 서버의 재량이며, resource 또는 audience 매개변수가 나타내는 서비스 또는 리소스의 요구사항에 대한 지식에 의해 결정될 수 있다.¶

subject_token

REQUIRED. 요청이 이루어지는 대상 당사자의 신원을 나타내는 보안 토큰이다. 일반적으로 이 토큰의 주체는 요청에 대한 응답으로 발급되는 보안 토큰의 주체가 된다.¶

subject_token_type

REQUIRED. subject_token 매개변수 안의 보안 토큰 유형을 나타내는 섹션 3에 설명된 식별자이다.¶

actor_token

OPTIONAL. 행동하는 당사자의 신원을 나타내는 보안 토큰이다. 일반적으로 이는 요청한 보안 토큰을 사용하고 주체를 대신하여 행동하도록 인가된 당사자가 된다.¶

actor_token_type

actor_token 매개변수 안의 보안 토큰 유형을 나타내는 섹션 3에 설명된 식별자이다. 이는 요청에 actor_token 매개변수가 존재할 때 REQUIRED이지만, 그렇지 않은 경우 포함되어서는 MUST NOT 안 된다.¶

요청을 처리할 때, 인가 서버는 표시된 토큰 유형에 대해 적절한 검증 절차를 수행해야 MUST 하며, actor token이 존재하는 경우 그 표시된 토큰 유형에 대해서도 적절한 검증 절차를 수행해야 한다. 특정 토큰의 유효성 기준과 세부 사항은 이 문서의 범위를 벗어나며 해당 토큰 유형과 그 내용에 특화되어 있다.¶

토큰 유형에 특화된 일회성 사용 또는 기타 의미론이 없는 경우, 토큰 교환을 수행하는 행위는 subject token 또는 actor token의 유효성에 아무런 영향을 주지 않는다. 또한 교환은 일회성 이벤트이며 입력 토큰과 출력 토큰 사이에 긴밀한 연결을 만들지 않는다. 따라서 예를 들어 출력 토큰의 만료 시간이 입력 토큰의 만료 시간에 영향을 받을 수는 있지만, 입력 토큰의 갱신 또는 연장이 출력 토큰의 속성에 반영될 것으로 기대되지는 않는다. 토큰 폐기 이벤트를 전파하는 것이 여전히 적절하거나 바람직할 수 있다. 그러나 그렇게 하는 것은 STS 프로토콜의 일반적인 속성이 아니며, 특정 구현, 토큰 유형 또는 배포에 특화될 것이다.¶

2.2. 응답

인가 서버는 토큰 교환 요청에 대해 [RFC6749]의 섹션 5에 명시된 것처럼 토큰 엔드포인트에서 오는 일반적인 OAuth 2.0 응답으로 응답한다. 추가 세부 사항과 설명은 다음 하위 절에서 제공된다.¶

2.3. 토큰 교환 예

다음 예는 OAuth 리소스 서버가 교환 중 클라이언트 역할을 맡는 가상의 토큰 교환을 보여 준다. 리소스 서버는 보호된 리소스 요청에서 받은 액세스 토큰을, 백엔드 서비스를 호출하는 데 사용할 새 토큰으로 교환한다 (예제의 추가 줄바꿈과 들여쓰기는 표시 목적일 뿐이다).¶

그림 1은 [RFC6750]의 섹션 2.1에 명시된 대로, Authorization 헤더에 OAuth 액세스 토큰을 포함한 보호된 리소스 요청을 리소스 서버가 수신하는 모습을 보여 준다.¶

 GET /resource HTTP/1.1
 Host: frontend.example.com
 Authorization: Bearer accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC

그림 2에서 리소스 서버는 토큰 교환을 위한 클라이언트 역할을 맡으며, 그림 1의 요청에서 가져온 액세스 토큰은 섹션 2.1에 명시된 요청을 사용하여 인가 서버로 전송된다. subject_token 매개변수의 값은 액세스 토큰을 전달하고, subject_token_type 매개변수의 값은 그것이 OAuth 2.0 액세스 토큰임을 나타낸다. 클라이언트 역할을 하는 리소스 서버는 HTTP Basic 인증 스킴을 사용하여 자신의 식별자와 비밀값으로 인가 서버에 인증한다. resource 매개변수는 발급된 토큰이 사용될 백엔드 서비스의 위치인 <https://backend.example.com/api>를 나타낸다.¶

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

 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
 &resource=https%3A%2F%2Fbackend.example.com%2Fapi
 &subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC
 &subject_token_type=
  urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token

인가 서버는 토큰 교환 요청에 제시된 클라이언트 자격 증명과 subject_token을 검증한다. resource 매개변수로부터 인가 서버는 요청에 적용할 적절한 정책을 결정할 수 있으며 <https://backend.example.com>에서 사용하기에 적합한 토큰을 발급한다. 그림 3에 표시된 응답의 access_token 매개변수는 새 토큰을 포함하며, 이 토큰 자체는 1분 동안 유효한 bearer OAuth 액세스 토큰이다. 그 토큰은 우연히 JWT이지만, 클라이언트에게는 그 구조와 형식이 불투명하므로 issued_token_type은 그것이 액세스 토큰임만 나타낸다.¶

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

 {
  "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQiOiJo
    dHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2FzLmV
    4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1MzMsIn
    N1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQedw6rx
    f59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIWvmDCM
    y5-kdXjwhw",
  "issued_token_type":
      "urn:ietf:params:oauth:token-type:access_token",
  "token_type":"Bearer",
  "expires_in":60
 }

그런 다음 리소스 서버는 그림 4에 예시된 것처럼 새로 획득한 액세스 토큰을 사용하여 백엔드 서버에 요청을 보낼 수 있다.¶

 GET /api HTTP/1.1
 Host: backend.example.com
 Authorization: Bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQ
    iOiJodHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2
    FzLmV4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1M
    zMsInN1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQe
    dw6rxf59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIW
    vmDCMy5-kdXjwhw

추가 예는 부록 A에서 확인할 수 있다.¶

4.1. "act" (행위자) 클레임

act (actor) 클레임은 JWT 안에서 위임이 발생했음을 표현하고 권한이 위임된 행동 당사자를 식별하는 수단을 제공한다. act 클레임 값은 JSON 객체이며, 그 JSON 객체의 멤버는 행위자를 식별하는 클레임이다. act 클레임을 구성하는 클레임은 행위자를 식별하고, 가능하면 행위자에 대한 추가 정보를 제공한다. 예를 들어, 두 클레임 iss와 sub의 조합이 행위자를 고유하게 식별하는 데 필요할 수 있다.¶

그러나 act 클레임 안의 클레임은 행위자의 신원에만 관련되며, 최상위 클레임과 같은 방식으로 포함하는 JWT의 유효성과는 관련되지 않는다. 따라서 비신원 클레임(예: exp, nbf, 및 aud)은 act 클레임 안에서 사용될 때 의미가 없으므로 사용되지 않는다.¶

그림 5는 JWT Claims Set 안의 act (actor) 클레임을 보여 준다. 토큰 자체의 클레임은 user@example.com에 관한 것이고, act 클레임은 admin@example.com이 현재 행위자임을 나타낸다.¶

 {
   "aud":"https://consumer.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904177,
   "nbf":1443904077,
   "sub":"user@example.com",
   "act":
   {
     "sub":"admin@example.com"
   }
 }

위임 체인은 하나의 act 클레임을 다른 act 클레임 안에 중첩하여 표현할 수 있다. 가장 바깥쪽 act 클레임은 현재 행위자를 나타내며, 중첩된 act 클레임은 이전 행위자를 나타낸다. 가장 오래된 행위자는 가장 깊게 중첩된다. 중첩된 act 클레임은 최초 요청 및 주체를 현재 행위자에 도달하기 전에 수행된 다양한 위임 단계와 연결하는 이력 추적 역할을 한다. 이러한 의미에서 현재 행위자는 전체 인가/위임 이력을 포함하는 것으로 간주되며, 여기에서 설명하는 중첩 구조로 자연스럽게 이어진다.¶

액세스 제어 정책을 적용할 목적으로, 토큰의 소비자는 토큰의 최상위 클레임과 act 클레임이 현재 행위자로 식별한 당사자만 고려해야 MUST 한다. 중첩된 act 클레임이 식별한 이전 행위자는 정보 제공용일 뿐이며 액세스 제어 결정에서 고려되어서는 안 된다.¶

그림 6의 다음 예는 JWT Claims Set 안의 중첩된 act (actor) 클레임을 보여 준다. 토큰 자체의 클레임은 user@example.com에 관한 것이고, act 클레임은 시스템 <https://service16.example.com>이 현재 행위자이며 <https://service77.example.com>가 이전 행위자였음을 나타낸다. 그러한 토큰은 service16이 service77의 호출에서 토큰을 수신하고, 인가 서버가 새로 발급된 토큰에 그 상황을 기록하면서 service26을 호출하기에 적합한 토큰으로 교환한 결과로 생성될 수 있다.¶

 {
   "aud":"https://service26.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904100,
   "nbf":1443904000,
   "sub":"user@example.com",
   "act":
   {
     "sub":"https://service16.example.com",
     "act":
     {
       "sub":"https://service77.example.com"
     }
   }
 }

OAuth 토큰 검사 응답의 최상위 멤버로 포함될 때, act는 같은 이름의 클레임과 동일한 의미론 및 형식을 가진다.¶

4.2. "scope" (범위) 클레임

scope 클레임의 값은 [RFC6749]의 섹션 3.3에 설명된 형식으로, 토큰과 관련된 범위의 공백으로 구분된 목록을 포함하는 JSON 문자열이다.¶

그림 7은 JWT Claims Set 안의 scope 클레임을 보여 준다.¶

 {
   "aud":"https://consumer.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904177,
   "nbf":1443904077,
   "sub":"dgaf4mvfs75Fci_FL3heQA",
   "scope":"email profile phone address"
 }

OAuth 2.0 Token Introspection [RFC7662]는 이미 토큰과 관련된 범위를 전달하기 위해 scope 매개변수를 정의한다.¶

4.3. "client_id" (클라이언트 식별자) 클레임

client_id 클레임은 토큰을 요청한 OAuth 2.0 [RFC6749] 클라이언트의 클라이언트 식별자를 전달한다.¶

그림 8의 다음 예는 식별자가 "s6BhdRkqt3"인 OAuth 2.0 클라이언트를 나타내는 JWT Claims Set 안의 client_id 클레임을 보여 준다.¶

 {
   "aud":"https://consumer.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904177,
   "sub":"user@example.com",
   "client_id":"s6BhdRkqt3"
 }

OAuth 2.0 Token Introspection [RFC7662]는 이미 토큰을 요청한 OAuth 2.0 클라이언트의 클라이언트 식별자로 client_id 매개변수를 정의한다.¶

4.4. "may_act" (인가된 행위자) 클레임

may_act 클레임은 한 당사자가 행위자가 되어 다른 당사자를 대신하여 행동하도록 인가되었다는 진술을 만든다. 예를 들어 subject_token이 토큰 교환 요청에서 토큰 엔드포인트에 제시될 때, subject token 안의 may_act 클레임은 클라이언트(또는 actor_token에서 식별된 당사자)가 요청된 위임 또는 가장에 참여하도록 인가되었는지를 인가 서버가 결정하는 데 사용될 수 있다. 클레임 값은 JSON 객체이며, JSON 객체의 멤버는 클레임을 포함한 JWT가 식별하는 당사자를 위해 행동할 자격이 있다고 주장되는 당사자를 식별하는 클레임이다. may_act 클레임을 구성하는 클레임은 인가된 행위자를 식별하고 가능하면 그에 관한 추가 정보를 제공한다. 예를 들어 두 클레임 iss와 sub의 조합은 인가된 행위자를 고유하게 식별하는 데 때때로 필요하며, email 클레임은 해당 당사자에 관한 추가로 유용한 정보를 제공하는 데 사용될 수 있다.¶

그러나 may_act 클레임 안의 클레임은 그 당사자의 신원에만 관련되며, 최상위 클레임과 같은 방식으로 포함하는 JWT의 유효성과는 관련되지 않는다. 따라서 exp, nbf, 및 aud와 같은 클레임은 may_act 클레임 안에서 사용될 때 의미가 없으므로 사용되지 않는다.¶

그림 9는 JWT Claims Set 안의 may_act 클레임을 보여 준다. 토큰 자체의 클레임은 user@example.com에 관한 것이고, may_act 클레임은 admin@example.com이 user@example.com을 대신하여 행동하도록 인가되었음을 나타낸다.¶

 {
   "aud":"https://consumer.example.com",
   "iss":"https://issuer.example.com",
   "exp":1443904177,
   "nbf":1443904077,
   "sub":"user@example.com",
   "may_act":
   {
     "sub":"admin@example.com"
   }
 }

OAuth 토큰 검사 응답의 최상위 멤버로 포함될 때, may_act는 같은 이름의 클레임과 동일한 의미론 및 형식을 가진다.¶

7.1. OAuth URI 등록

IANA는 "OAuth Parameters" 레지스트리 [IANA.OAuth.Parameters]의 "OAuth URI" 하위 레지스트리에 다음 값을 등록했다. "OAuth URI" 하위 레지스트리는 [RFC6755]에 의해 설정되었다.¶

• URN: urn:ietf:params:oauth:grant-type:token-exchange¶
• 일반 이름: OAuth 2.0용 토큰 교환 grant type¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 2.1¶

• URN: urn:ietf:params:oauth:token-type:access_token¶
• 일반 이름: OAuth 2.0 액세스 토큰의 토큰 유형 URI¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 3¶

• URN: urn:ietf:params:oauth:token-type:refresh_token¶
• 일반 이름: OAuth 2.0 refresh token의 토큰 유형 URI¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 3¶

• URN: urn:ietf:params:oauth:token-type:id_token¶
• 일반 이름: ID Token의 토큰 유형 URI¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 3¶

• URN: urn:ietf:params:oauth:token-type:saml1¶
• 일반 이름: base64url로 인코딩된 SAML 1.1 어서션의 토큰 유형 URI¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 3¶

• URN: urn:ietf:params:oauth:token-type:saml2¶
• 일반 이름: base64url로 인코딩된 SAML 2.0 어서션의 토큰 유형 URI¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 3¶

7.2. OAuth 매개변수 등록

IANA는 "OAuth Parameters" 레지스트리 [IANA.OAuth.Parameters]의 "OAuth Parameters" 하위 레지스트리에 다음 값을 등록했다. "OAuth Parameters" 하위 레지스트리는 [RFC6749]에 의해 설정되었다.¶

• 매개변수 이름: audience¶
• 매개변수 사용 위치: 토큰 요청¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 2.1¶

• 매개변수 이름: requested_token_type¶
• 매개변수 사용 위치: 토큰 요청¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 2.1¶

• 매개변수 이름: subject_token¶
• 매개변수 사용 위치: 토큰 요청¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 2.1¶

• 매개변수 이름: subject_token_type¶
• 매개변수 사용 위치: 토큰 요청¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 2.1¶

• 매개변수 이름: actor_token¶
• 매개변수 사용 위치: 토큰 요청¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 2.1¶

• 매개변수 이름: actor_token_type¶
• 매개변수 사용 위치: 토큰 요청¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 2.1¶

• 매개변수 이름: issued_token_type¶
• 매개변수 사용 위치: 토큰 응답¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 2.2.1¶

7.3. OAuth 액세스 토큰 유형 등록

IANA는 "OAuth Parameters" 레지스트리 [IANA.OAuth.Parameters]의 "OAuth Access Token Types" 하위 레지스트리에 다음 액세스 토큰 유형을 등록했다. "OAuth Access Token Types" 하위 레지스트리는 [RFC6749]에 의해 설정되었다.¶

• 유형 이름: N_A¶
• 추가 토큰 엔드포인트 응답 매개변수: 없음¶
• HTTP 인증 스킴: 없음¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 2.2.1¶

7.4. JSON Web Token 클레임 등록

IANA는 "JSON Web Token (JWT)" 레지스트리 [IANA.JWT]의 "JSON Web Token Claims" 하위 레지스트리에 다음 클레임을 등록했다. "JSON Web Token Claims" 하위 레지스트리는 [JWT]에 의해 설정되었다.¶

• 클레임 이름: act¶
• 클레임 설명: 행위자¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 4.1¶

• 클레임 이름: scope¶
• 클레임 설명: 범위 값¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 4.2¶

• 클레임 이름: client_id¶
• 클레임 설명: 클라이언트 식별자¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 4.3¶

• 클레임 이름: may_act¶
• 클레임 설명: 인가된 행위자 - 행위자가 되도록 인가된 당사자¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 4.4¶

7.5. OAuth 토큰 검사 응답 등록

IANA는 "OAuth Parameters" 레지스트리 [IANA.OAuth.Parameters]의 "OAuth Token Introspection Response" 레지스트리에 다음 값을 등록했다. "OAuth Token Introspection Response" 레지스트리는 [RFC7662]에 의해 설정되었다.¶

• 이름: act¶
• 설명: 행위자¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 4.1¶

• 이름: may_act¶
• 설명: 인가된 행위자 - 행위자가 되도록 인가된 당사자¶
• 변경 관리자: IESG¶
• 명세 문서: RFC 8693의 섹션 4.4¶

A.1. 가장 토큰 교환 예

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

 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
 &audience=urn%3Aexample%3Acooperation-context
 &subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc
   zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI
   uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTA2MDAsIm5iZiI6MTQ0MTkwOTAwMCwic
   3ViIjoiYmRjQGV4YW1wbGUubmV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN
   0b3J5In0.PRBg-jXn4cJuj1gmYXFiGkZzRuzbXZ_sDxdE98ddW44ufsbWLKd3JJ1VZ
   hF64pbTtfjy4VXFVBDaQpKjn5JzAw
 &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt

  {
    "aud":"https://as.example.com",
    "iss":"https://original-issuer.example.net",
    "exp":1441910600,
    "nbf":1441909000,
    "sub":"bdc@example.net",
    "scope":"orders profile history"
  }

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

 {
  "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4
    6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l
    eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic3ViIjoiYmRjQGV4YW1wbGUub
    mV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN0b3J5In0.rMdWpSGNACTvnF
    uOL74sYZ6MVuld2Z2WkGLmQeR9ztj6w2OXraQlkJmGjyiCq24kcB7AI2VqVxl3wSW
    nVKh85A",
  "issued_token_type":
    "urn:ietf:params:oauth:token-type:access_token",
  "token_type":"Bearer",
  "expires_in":3600
 }

  {
    "aud":"urn:example:cooperation-context",
    "iss":"https://as.example.com",
    "exp":1441913610,
    "sub":"bdc@example.net",
    "scope":"orders profile history"
  }

A.2. 위임 토큰 교환 예

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

 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
 &audience=urn%3Aexample%3Acooperation-context
 &subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc
   zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI
   uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInNjb3BlIjoic3RhdHVzIGZlZ
   WQiLCJzdWIiOiJ1c2VyQGV4YW1wbGUubmV0IiwibWF5X2FjdCI6eyJzdWIiOiJhZG1
   pbkBleGFtcGxlLm5ldCJ9fQ.4rPRSWihQbpMIgAmAoqaJojAxj-p2X8_fAtAGTXrvM
   xU-eEZHnXqY0_AOZgLdxw5DyLzua8H_I10MCcckF-Q_g
 &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
 &actor_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwczo
   vL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXIuZ
   XhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInN1YiI6ImFkbWluQGV4YW1wbGU
   ubmV0In0.7YQ-3zPfhUvzje5oqw8COCvN5uP6NsKik9CVV6cAOf4QKgM-tKfiOwcgZ
   oUuDL2tEs6tqPlcBlMjiSzEjm3yBg
 &actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt

  {
    "aud":"https://as.example.com",
    "iss":"https://original-issuer.example.net",
    "exp":1441910060,
    "scope":"status feed",
    "sub":"user@example.net",
    "may_act":
    {
      "sub":"admin@example.net"
    }
  }

  {
    "aud":"https://as.example.com",
    "iss":"https://original-issuer.example.net",
    "exp":1441910060,
    "sub":"admin@example.net"
  }

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

 {
  "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4
    6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l
    eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic2NvcGUiOiJzdGF0dXMgZmVlZ
    CIsInN1YiI6InVzZXJAZXhhbXBsZS5uZXQiLCJhY3QiOnsic3ViIjoiYWRtaW5AZX
    hhbXBsZS5uZXQifX0.3paKl9UySKYB5ng6_cUtQ2qlO8Rc_y7Mea7IwEXTcYbNdwG
    9-G1EKCFe5fW3H0hwX-MSZ49Wpcb1SiAZaOQBtw",
  "issued_token_type":"urn:ietf:params:oauth:token-type:jwt",
  "token_type":"N_A",
  "expires_in":3600
 }

  {
    "aud":"urn:example:cooperation-context",
    "iss":"https://as.example.com",
    "exp":1441913610,
    "scope":"status feed",
    "sub":"user@example.net",
    "act":
    {
      "sub":"admin@example.net"
    }
  }