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. 요구 사항 표기법 및 규칙

이 문서에서 핵심어 "반드시", "해서는 안 됩니다", "필수입니다", "하여야 합니다", "하여서는 안 됩니다", "하는 것이 좋습니다", "하지 않는 것이 좋습니다", "권장됩니다", "권장되지 않습니다", "할 수 있습니다" 및 "선택 사항입니다"는 여기에서 보인 것처럼 모두 대문자로 나타나는 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석해야 합니다.¶

1.3. 용어

이 사양에서는 OAuth 2.0 [RFC6749]에서 정의된 "액세스 토큰 유형", "권한 부여 서버", "클라이언트", "클라이언트 식별자", "리소스 서버", "토큰 엔드포인트", "토큰 요청" 및 "토큰 응답" 이라는 용어와 JSON 웹 토큰(JWT) [JWT]에서 정의된 "Base64url 인코딩", "클레임" 및 "JWT 클레임 집합"이라는 용어를 사용합니다.¶

2.1. 요청

클라이언트는 권한 부여 서버의 토큰 엔드포인트에 4.5절의 [RFC6749]에서 정의된 확장 권한 부여 유형 메커니즘을 사용하여 토큰 요청을 보내 보안 토큰을 요청합니다.¶

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

클라이언트는 HTTP POST 메서드를 사용하여 확장 권한 부여 유형으로 토큰 엔드포인트에 토큰 교환 요청을 보냅니다. 다음 매개변수는 HTTP 요청 엔터티 본문에 application/x-www-form-urlencoded 형식과 UTF-8 문자 인코딩을 사용하여 포함되며, 이는 부록 B 의 [RFC6749]에 설명되어 있습니다.¶

grant_type

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

resource

선택 사항입니다. 클라이언트가 요청된 보안 토큰을 사용하려는 대상 서비스 또는 리소스를 나타내는 URI입니다. 이를 통해 권한 부여 서버는 대상에 적합한 정책을 적용할 수 있으며, 예를 들어 발급할 토큰의 유형과 내용을 결정하거나 토큰을 어떻게 암호화할지 여부를 결정할 수 있습니다. 많은 경우 클라이언트는 상호 작용하는 시스템의 논리적 구성을 알지 못하며 토큰을 사용하려는 서비스의 URI만 알고 있습니다. resource 매개변수를 사용하면 클라이언트는 권한 부여 서버에 발급된 토큰을 사용할 위치를, 일반적으로 https URL로 제공하여 해당 리소스에 액세스할 때 사용될 것과 동일한 형식으로 토큰 교환 요청에 지정할 수 있습니다. 권한 부여 서버는 일반적으로 리소스 URI 값에서 적절한 정책으로 매핑할 수 있습니다. resource 매개변수의 값은 반드시 4.3절의 [RFC3986]에 규정된 절대 URI여야 하며, 쿼리 구성 요소를 포함할 수 있지만 프래그먼트 구성 요소는 포함해서는 안 됩니다. 여러 resource 매개변수를 사용하여 발급된 토큰이 나열된 여러 리소스에서 사용되도록 의도되었음을 나타낼 수 있습니다. resource 매개변수에 대한 추가 배경 정보 및 사용 방법은 [OAUTH-RESOURCE]를 참조하십시오.¶

audience

선택 사항입니다. 클라이언트가 요청된 보안 토큰을 사용하려는 대상 서비스의 논리적 이름입니다. 이는 resource 매개변수와 유사한 목적을 제공하지만 클라이언트가 대상 서비스의 논리적 이름을 제공합니다. 이 이름을 해석하려면 값이 클라이언트와 권한 부여 서버 모두가 이해하는 것이어야 합니다. OAuth 클라이언트 식별자, SAML 엔터티 식별자 [OASIS.saml-core-2.0-os] 및 OpenID Connect 발급자 식별자 [OpenID.Core]는 audience 매개변수 값으로 사용할 수 있는 항목의 예입니다. 그러나 특정 권한 부여 서버에서 사용하는 audience 값은 의도된 유형의 값으로 올바르게 해석되도록 해당 서버 내에서 고유해야 합니다. 여러 audience 매개변수를 사용하여 발급된 토큰이 나열된 여러 대상에서 사용되도록 의도되었음을 나타낼 수 있습니다. audience 및 resource 매개변수를 함께 사용하여 논리적 이름과 리소스 URI가 혼합된 여러 대상 서비스를 나타낼 수 있습니다.¶

scope

선택 사항입니다. 3.3절의 [RFC6749]에서 정의된, 공백으로 구분되고 대소문자를 구분하는 문자열 목록으로, 클라이언트가 토큰이 사용될 서비스 또는 리소스의 맥락에서 요청된 보안 토큰의 원하는 범위를 지정할 수 있게 합니다. 범위의 값과 관련 의미는 서비스별로 다르며 관련 서비스 문서에 설명되어야 합니다.¶

requested_token_type

선택 사항입니다. 요청된 보안 토큰 유형을 나타내는 3절에 설명된 식별자입니다. 요청된 유형을 지정하지 않으면 발급되는 토큰 유형은 권한 부여 서버의 재량에 따르며 resource 또는 audience 매개변수로 나타낸 서비스 또는 리소스의 요구 사항에 대한 지식에 따라 결정될 수 있습니다.¶

subject_token

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

subject_token_type

필수입니다. subject_token 매개변수에 있는 보안 토큰의 유형을 나타내는 3절에 설명된 식별자입니다.¶

actor_token

선택 사항입니다. 행동하는 당사자의 신원을 나타내는 보안 토큰입니다. 일반적으로 이는 요청된 보안 토큰을 사용하고 주체를 대신하여 행동할 권한이 부여된 당사자입니다.¶

actor_token_type

actor_token 매개변수에 있는 보안 토큰의 유형을 나타내는 3절에 설명된 식별자입니다. 요청에 actor_token 매개변수가 있는 경우 필수이지만, 그렇지 않은 경우 포함해서는 안 됩니다.¶

요청을 처리할 때 권한 부여 서버는 표시된 토큰 유형에 적합한 검증 절차를 반드시 수행해야 하며, 행위자 토큰이 있는 경우에는 표시된 해당 토큰 유형에 대해서도 적절한 검증 절차를 수행해야 합니다. 특정 토큰의 유효성 기준과 세부 사항은 이 문서의 범위를 벗어나며 각 토큰 유형 및 그 내용에 따라 달라집니다.¶

일회성 사용 또는 토큰 유형에 특정한 다른 의미가 없는 경우 토큰 교환을 수행하는 행위는 주체 토큰이나 행위자 토큰의 유효성에 아무런 영향을 미치지 않습니다. 또한 교환은 일회성 이벤트이며 입력 토큰과 출력 토큰 사이에 긴밀한 연결을 만들지 않으므로, 예를 들어 출력 토큰의 만료 시간이 입력 토큰의 만료 시간에 영향을 받을 수 있더라도 입력 토큰의 갱신 또는 연장이 출력 토큰의 속성에 반영되지는 않습니다. 토큰 취소 이벤트를 전파하는 것이 여전히 적절하거나 바람직할 수 있습니다. 그러나 그렇게 하는 것은 STS 프로토콜의 일반적인 속성이 아니며 특정 구현, 토큰 유형 또는 배포에 따라 달라집니다.¶

2.2. 응답

권한 부여 서버는 5절의 [RFC6749]에 규정된 대로 토큰 엔드포인트의 일반적인 OAuth 2.0 응답으로 토큰 교환 요청에 응답합니다. 추가적인 세부 사항과 설명은 다음 하위 절에서 제공합니다.¶

2.3. 토큰 교환 예시

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

그림 1은 리소스 서버가 Authorization 헤더에 OAuth 액세스 토큰이 포함된 보호된 리소스 요청을 수신하는 모습을 보여 주며, 이는 2.1절의 [RFC6750]에 규정되어 있습니다.¶

 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분 동안 유효한 전달자 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 (행위자) 클레임은 JWT 내에서 위임이 이루어졌음을 표현하고 권한이 위임된 행동 당사자를 식별하는 수단을 제공합니다. act 클레임 값은 JSON 객체이며, JSON 객체의 멤버는 행위자를 식별하는 클레임입니다. act 클레임을 구성하는 클레임은 행위자를 식별하고 경우에 따라 행위자에 관한 추가 정보를 제공합니다. 예를 들어, 두 클레임 iss와 sub의 조합이 행위자를 고유하게 식별하는 데 필요할 수 있습니다.¶

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

그림 5는 JWT 클레임 집합 내의 act (행위자) 클레임을 보여 줍니다. 토큰 자체의 클레임은 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 클레임에 의해 현재 행위자로 식별된 당사자만 고려해야 합니다. 중첩된 act 클레임에 의해 식별된 이전 행위자는 정보 제공용일 뿐이며 액세스 제어 결정에서 고려해서는 안 됩니다.¶

그림 6의 다음 예시는 JWT 클레임 집합 내에 중첩된 act (행위자) 클레임을 보여 줍니다. 토큰 자체의 클레임은 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 클레임의 값은 토큰과 연관된 범위를 공백으로 구분한 목록을 포함하는 JSON 문자열이며, 그 형식은 3.3절의 [RFC6749]에 설명되어 있습니다.¶

그림 7은 JWT 클레임 집합 내의 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 토큰 검사 [RFC7662]에서는 이미 토큰과 연관된 범위를 전달하기 위한 scope 매개변수를 정의합니다.¶

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

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

그림 8의 다음 예시는 식별자가 "s6BhdRkqt3"인 OAuth 2.0 클라이언트를 나타내는 JWT 클레임 집합 내의 client_id 클레임을 보여 줍니다.¶

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

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

4.4. "may_act" (권한이 부여된 행위자) 클레임

may_act 클레임은 한 당사자가 행위자가 되어 다른 당사자를 대신하여 행동할 권한이 부여되었음을 나타냅니다. 예를 들어 토큰 교환 요청에서 subject_token이 토큰 엔드포인트에 제시될 때 이 클레임을 사용할 수 있으며, 주체 토큰의 may_act 클레임은 권한 부여 서버가 클라이언트(또는 actor_token에서 식별된 당사자)가 요청된 위임 또는 가장을 수행할 권한이 있는지 결정하는 데 사용할 수 있습니다. 클레임 값은 JSON 객체이며, JSON 객체의 멤버는 해당 클레임을 포함하는 JWT에 의해 식별된 당사자를 대신하여 행동할 자격이 있다고 선언된 당사자를 식별하는 클레임입니다. may_act 클레임을 구성하는 클레임은 권한이 부여된 행위자를 식별하고 경우에 따라 추가 정보를 제공합니다. 예를 들어 두 클레임 iss 및 sub의 조합은 권한이 부여된 행위자를 고유하게 식별하는 데 필요한 경우가 있으며, email 클레임은 해당 당사자에 관한 추가적인 유용한 정보를 제공하는 데 사용할 수 있습니다.¶

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

그림 9는 JWT 클레임 집합 내의 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" 레지스트리의 "OAuth URI" 하위 레지스트리 [IANA.OAuth.Parameters]에 다음 값을 등록했습니다. "OAuth URI" 하위 레지스트리는 [RFC6755]에 의해 설정되었습니다.¶

• URN: urn:ietf:params:oauth:grant-type:token-exchange¶
• 일반 이름: OAuth 2.0용 토큰 교환 권한 부여 유형¶
• 변경 관리 주체: 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 새로 고침 토큰용 토큰 유형 URI¶
• 변경 관리 주체: IESG¶
• 사양 문서: RFC 8693의 3절¶

• URN: urn:ietf:params:oauth:token-type:id_token¶
• 일반 이름: ID 토큰용 토큰 유형 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" 레지스트리의 "OAuth Parameters" 하위 레지스트리 [IANA.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" 레지스트리의 "OAuth Access Token Types" 하위 레지스트리 [IANA.OAuth.Parameters]에 다음 액세스 토큰 유형을 등록했습니다. "OAuth Access Token Types" 하위 레지스트리는 [RFC6749]에 의해 설정되었습니다.¶

• 유형 이름: N_A¶
• 추가 토큰 엔드포인트 응답 매개변수: 없음¶
• HTTP 인증 체계: 없음¶
• 변경 관리 주체: IESG¶
• 사양 문서: RFC 8693의 2.2.1절¶

7.4. JSON 웹 토큰 클레임 등록

IANA는 "JSON Web Token (JWT)" 레지스트리의 "JSON Web Token Claims" 하위 레지스트리 [IANA.JWT]에 다음 클레임을 등록했습니다. "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" 레지스트리의 "OAuth Token Introspection Response" 레지스트리 [IANA.OAuth.Parameters]에 다음 값을 등록했습니다. "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"
    }
  }