OAuth Working Group M. Jones Internet-Draft A. Nadalin Intended status: Standards Track Microsoft Expires: January 7, 2020 B. Campbell, Ed. Ping Identity J. Bradley Yubico C. Mortimore Salesforce July 6, 2019 OAuth 2.0 Token Exchange draft-ietf-oauth-token-exchange-18 Abstract This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 7, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Jones, et al. Expires January 7, 2020 [Page 1] Internet-Draft OAuth 2.0 Token Exchange July 2019 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Delegation vs. Impersonation Semantics . . . . . . . . . 4 1.2. Requirements Notation and Conventions . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2. Token Exchange Request and Response . . . . . . . . . . . . . 6 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Relationship Between Resource, Audience and Scope . . 9 2.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1. Successful Response . . . . . . . . . . . . . . . . . 9 2.2.2. Error Response . . . . . . . . . . . . . . . . . . . 11 2.3. Example Token Exchange . . . . . . . . . . . . . . . . . 11 3. Token Type Identifiers . . . . . . . . . . . . . . . . . . . 13 4. JSON Web Token Claims and Introspection Response Parameters . 15 4.1. "act" (Actor) Claim . . . . . . . . . . . . . . . . . . . 15 4.2. "scope" (Scopes) Claim . . . . . . . . . . . . . . . . . 17 4.3. "client_id" (Client Identifier) Claim . . . . . . . . . . 18 4.4. "may_act" (Authorized Actor) Claim . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7.1. OAuth URI Registration . . . . . . . . . . . . . . . . . 20 7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 20 7.2. OAuth Parameters Registration . . . . . . . . . . . . . . 21 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 21 7.3. OAuth Access Token Type Registration . . . . . . . . . . 22 7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 22 7.4. JSON Web Token Claims Registration . . . . . . . . . . . 22 7.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 22 7.5. OAuth Token Introspection Response Registration . . . . . 23 7.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 23 7.6. OAuth Extensions Error Registration . . . . . . . . . . . 23 7.6.1. Registry Contents . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . 24 Appendix A. Additional Token Exchange Examples . . . . . . . . . 26 A.1. Impersonation Token Exchange Example . . . . . . . . . . 26 A.1.1. Token Exchange Request . . . . . . . . . . . . . . . 26 A.1.2. Subject Token Claims . . . . . . . . . . . . . . . . 26 A.1.3. Token Exchange Response . . . . . . . . . . . . . . . 27 Jones, et al. Expires January 7, 2020 [Page 2] Internet-Draft OAuth 2.0 Token Exchange July 2019 A.1.4. Issued Token Claims . . . . . . . . . . . . . . . . . 27 A.2. Delegation Token Exchange Example . . . . . . . . . . . . 28 A.2.1. Token Exchange Request . . . . . . . . . . . . . . . 28 A.2.2. Subject Token Claims . . . . . . . . . . . . . . . . 28 A.2.3. Actor Token Claims . . . . . . . . . . . . . . . . . 29 A.2.4. Token Exchange Response . . . . . . . . . . . . . . . 29 A.2.5. Issued Token Claims . . . . . . . . . . . . . . . . . 30 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 31 Appendix C. Document History . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction A security token is a set of information that facilitates the sharing of identity and security information in heterogeneous environments or across security domains. Examples of security tokens include JSON Web Tokens (JWTs) [JWT] and SAML 2.0 Assertions [OASIS.saml-core-2.0-os]. Security tokens are typically signed to achieve integrity and sometimes also encrypted to achieve confidentiality. Security tokens are also sometimes described as Assertions, such as in [RFC7521]. A Security Token Service (STS) is a service capable of validating security tokens provided to it and issuing new security tokens in response, which enables clients to obtain appropriate access credentials for resources in heterogeneous environments or across security domains. Web Service clients have used WS-Trust [WS-Trust] as the protocol to interact with an STS for token exchange. While WS-Trust uses XML and SOAP, the trend in modern Web development has been towards RESTful patterns and JSON. The OAuth 2.0 Authorization Framework [RFC6749] and OAuth 2.0 Bearer Tokens [RFC6750] have emerged as popular standards for authorizing third-party applications' access to HTTP and RESTful resources. The conventional OAuth 2.0 interaction involves the exchange of some representation of resource owner authorization for an access token, which has proven to be an extremely useful pattern in practice, however, its input and output are somewhat too constrained as is to fully accommodate a security token exchange framework. This specification defines a protocol extending OAuth 2.0 that enables clients to request and obtain security tokens from authorization servers acting in the role of an STS. Similar to OAuth 2.0, this specification focuses on client developer simplicity and requires only an HTTP client and JSON parser, which are nearly universally available in modern development environments. The STS protocol defined in this specification is not itself RESTful (an STS doesn't lend itself particularly well to a REST approach) but does Jones, et al. Expires January 7, 2020 [Page 3] Internet-Draft OAuth 2.0 Token Exchange July 2019 utilize communication patterns and data formats that should be familiar to developers accustomed to working with RESTful systems. A new grant type for a token exchange request and the associated specific parameters for such a request to the token endpoint are defined by this specification. A token exchange response is a normal OAuth 2.0 response from the token endpoint with a few additional parameters defined herein to provide information to the client. The entity that makes the request to exchange tokens is considered the client in the context of the token exchange interaction. However, that does not restrict usage of this profile to traditional OAuth clients. An OAuth resource server, for example, might assume the role of the client during token exchange in order to trade an access token, which it received in a protected resource request, for a new token that is appropriate to include in a call to a backend service. The new token might be an access token that is more narrowly scoped for the downstream service or it could be an entirely different kind of token. The scope of this specification is limited to the definition of a basic request and response protocol for an STS-style token exchange utilizing OAuth 2.0. Although a few new JWT claims are defined that enable delegation semantics to be expressed, the specific syntax, semantics and security characteristics of the tokens themselves (both those presented to the authorization server and those obtained by the client) are explicitly out of scope and no requirements are placed on the trust model in which an implementation might be deployed. Additional profiles may provide more detailed requirements around the specific nature of the parties and trust involved, such as whether signing and/or encryption of tokens is needed or if proof-of- possession style tokens will be required or issued; however, such details will often be policy decisions made with respect to the specific needs of individual deployments and will be configured or implemented accordingly. The security tokens obtained may be used in a number of contexts, the specifics of which are also beyond the scope of this specification. 1.1. Delegation vs. Impersonation Semantics One common use case for an STS (as alluded to in the previous section) is to allow a resource server A to make calls to a backend service C on behalf of the requesting user B. Depending on the local site policy and authorization infrastructure, it may be desirable for A to use its own credentials to access C along with an annotation of some form that A is acting on behalf of B ("delegation"), or for A to be granted a limited access credential to C but that continues to Jones, et al. Expires January 7, 2020 [Page 4] Internet-Draft OAuth 2.0 Token Exchange July 2019 identify B as the authorized entity ("impersonation"). Delegation and impersonation can be useful concepts in other scenarios involving multiple participants as well. When principal A impersonates principal B, A is given all the rights that B has within some defined rights context and is indistinguishable from B in that context. Thus, when principal A impersonates principal B, then insofar as any entity receiving such a token is concerned, they are actually dealing with B. It is true that some members of the identity system might have awareness that impersonation is going on, but it is not a requirement. For all intents and purposes, when A is impersonating B, A is B. Delegation semantics are different than impersonation semantics, though the two are closely related. With delegation semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated some of its rights to A, any actions taken are being taken by A representing B. In a sense, A is an agent for B. Delegation and impersonation are not inclusive of all situations. When a principal is acting directly on its own behalf, for example, neither delegation nor impersonation are in play. They are, however, the more common semantics operating for token exchange and, as such, are given more direct treatment in this specification. Delegation semantics are typically expressed in a token by including information about both the primary subject of the token as well as the actor to whom that subject has delegated some of its rights. Such a token is sometimes referred to as a composite token because it is composed of information about multiple subjects. Typically, in the request, the "subject_token" represents the identity of the party on behalf of whom the token is being requested while the "actor_token" represents the identity of the party to whom the access rights of the issued token are being delegated. A composite token issued by the authorization server will contain information about both parties. When and if a composite token is issued is at the discretion of the authorization server and applicable policy and configuration. The specifics of representing a composite token and even whether or not such a token will be issued depend on the details of the implementation and the kind of token. The representations of composite tokens that are not JWTs are beyond the scope of this specification. The "actor_token" request parameter, however, does provide a means for providing information about the desired actor and the JWT "act" claim can provide a representation of a chain of delegation. Jones, et al. Expires January 7, 2020 [Page 5] Internet-Draft OAuth 2.0 Token Exchange July 2019 1.2. Requirements Notation and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.3. Terminology This specification uses the terms "access token type", "authorization server", "client", "client identifier", "resource server", "token endpoint", "token request", and "token response" defined by OAuth 2.0 [RFC6749], and the terms "Base64url Encoding", "Claim", and "JWT Claims Set" defined by JSON Web Token (JWT) [JWT]. 2. Token Exchange Request and Response 2.1. Request A client requests a security token by making a token request to the authorization server's token endpoint using the extension grant type mechanism defined in Section 4.5 of [RFC6749]. Client authentication to the authorization server is done using the normal mechanisms provided by OAuth 2.0. Section 2.3.1 of [RFC6749] defines password-based authentication of the client, however, client authentication is extensible and other mechanisms are possible. For example, [RFC7523] defines client authentication using bearer JSON Web Tokens (JWTs) [JWT]. The supported methods of client authentication and whether or not to allow unauthenticated or unidentified clients are deployment decisions that are at the discretion of the authorization server. Note that omitting client authentication allows for a compromised token to be leveraged via an STS into other tokens by anyone possessing the compromised token. Thus client authentication allows for additional authorization checks by the STS as to which entities are permitted to impersonate or receive delegations from other entities. The client makes a token exchange request to the token endpoint with an extension grant type using the HTTP "POST" method. The following parameters are included in the HTTP request entity-body using the "application/x-www-form-urlencoded" format with a character encoding of UTF-8 as described in Appendix B of RFC6749 [RFC6749]. grant_type REQUIRED. The value "urn:ietf:params:oauth:grant-type:token- exchange" indicates that a token exchange is being performed. Jones, et al. Expires January 7, 2020 [Page 6] Internet-Draft OAuth 2.0 Token Exchange July 2019 resource OPTIONAL. A URI that indicates the target service or resource where the client intends to use the requested security token. This enables the authorization server to apply policy as appropriate for the target, such as determining the type and content of the token to be issued or if and how the token is to be encrypted. In many cases, a client will not have knowledge of the logical organization of the systems with which it interacts and will only know a URI of the service where it intends to use the token. The "resource" parameter allows the client to indicate to the authorization server where it intends to use the issued token by providing the location, typically as an https URL, in the token exchange request in the same form that will be used to access that resource. The authorization server will typically have the capability to map from a resource URI value to an appropriate policy. The value of the "resource" parameter MUST be an absolute URI, as specified by Section 4.3 of [RFC3986], which MAY include a query component and MUST NOT include a fragment component. Multiple "resource" parameters may be used to indicate that the issued token is intended to be used at the multiple resources listed. audience OPTIONAL. The logical name of the target service where the client intends to use the requested security token. This serves a purpose similar to the "resource" parameter, but with the client providing a logical name for the target service. Interpretation of the name requires that the value be something that both the client and the authorization server understand. An OAuth client identifier, a SAML entity identifier [OASIS.saml-core-2.0-os], an OpenID Connect Issuer Identifier [OpenID.Core], are examples of things that might be used as "audience" parameter values. However, "audience" values used with a given authorization server must be unique within that server, to ensure that they are properly interpreted as the intended type of value. Multiple "audience" parameters may be used to indicate that the issued token is intended to be used at the multiple audiences listed. The "audience" and "resource" parameters may be used together to indicate multiple target services with a mix of logical names and resource URIs. scope OPTIONAL. A list of space-delimited, case-sensitive strings, as defined in Section 3.3 of [RFC6749], that allow the client to specify the desired scope of the requested security token in the context of the service or resource where the token will be used. The values and associated semantics of scope are service specific Jones, et al. Expires January 7, 2020 [Page 7] Internet-Draft OAuth 2.0 Token Exchange July 2019 and expected to be described in the relevant service documentation. requested_token_type OPTIONAL. An identifier, as described in Section 3, for the type of the requested security token. If the requested type is unspecified, the issued token type is at the discretion of the authorization server and may be dictated by knowledge of the requirements of the service or resource indicated by the "resource" or "audience" parameter. subject_token REQUIRED. A security token that represents the identity of the party on behalf of whom the request is being made. Typically, the subject of this token will be the subject of the security token issued in response to the request. subject_token_type REQUIRED. An identifier, as described in Section 3, that indicates the type of the security token in the "subject_token" parameter. actor_token OPTIONAL. A security token that represents the identity of the acting party. Typically, this will be the party that is authorized to use the requested security token and act on behalf of the subject. actor_token_type An identifier, as described in Section 3, that indicates the type of the security token in the "actor_token" parameter. This is REQUIRED when the "actor_token" parameter is present in the request but MUST NOT be included otherwise. In processing the request, the authorization server MUST perform the appropriate validation procedures for the indicated token type and, if the actor token is present, also perform the appropriate validation procedures for its indicated token type. The validity criteria and details of any particular token are beyond the scope of this document and are specific to the respective type of token and its content. In the absence of one-time-use or other semantics specific to the token type, the act of performing a token exchange has no impact on the validity of the subject token or actor token. Furthermore, the exchange is a one-time event and does not create a tight linkage between the input and output tokens, so that (for example) while the expiration time of the output token may be influenced by that of the Jones, et al. Expires January 7, 2020 [Page 8] Internet-Draft OAuth 2.0 Token Exchange July 2019 input token, renewal or extension of the input token is not expected to be reflected in the output token's properties. It may still be appropriate or desirable to propagate token revocation events, however, doing so is not a general property of the STS protocol a would be specific to a particular token type or deployment/ implementation. 2.1.1. Relationship Between Resource, Audience and Scope When requesting a token, the client can indicate the desired target service(s) where it intends to use that token by way of the "audience" and "resource" parameters, as well as indicating the desired scope of the requested token using the "scope" parameter. The semantics of such a request are that the client is asking for a token with the requested scope that is usable at all the requested target services. Effectively, the requested access rights of the token are the cartesian product of all the scopes at all the target services. An authorization server may be unwilling or unable to fulfill any token request but the likelihood of an unfulfillable request is significantly higher when very broad access rights are being solicited. As such, in the absence of specific knowledge about the relationship of systems in a deployment, clients should exercise discretion in the breadth of the access requested, particularly the number of target services. An authorization server can use the "invalid_target" error code, defined in Section 2.2.2, to inform a client that it requested access to too many target services simultaneously. 2.2. Response The authorization server responds to a token exchange request with a normal OAuth 2.0 response from the token endpoint, as specified in Section 5 of [RFC6749]. Additional details and explanation are provided in the following subsections. 2.2.1. Successful Response If the request is valid and meets all policy and other criteria of the authorization server, a successful token response is constructed by adding the following parameters to the entity-body of the HTTP response using the "application/json" media type, as specified by [RFC8259], and an HTTP 200 status code. The parameters are serialized into a JavaScript Object Notation (JSON) structure by adding each parameter at the top level. Parameter names and string values are included as JSON strings. Numerical values are included Jones, et al. Expires January 7, 2020 [Page 9] Internet-Draft OAuth 2.0 Token Exchange July 2019 as JSON numbers. The order of parameters does not matter and can vary. access_token REQUIRED. The security token issued by the authorization server in response to the token exchange request. The "access_token" parameter from Section 5.1 of [RFC6749] is used here to carry the requested token, which allows this token exchange protocol to use the existing OAuth 2.0 request and response constructs defined for the token endpoint. The identifier "access_token" is used for historical reasons and the issued token need not be an OAuth access token. issued_token_type REQUIRED. An identifier, as described in Section 3, for the representation of the issued security token. token_type REQUIRED. A case-insensitive value specifying the method of using the access token issued, as specified in Section 7.1 of [RFC6749]. It provides the client with information about how to utilize the access token to access protected resources. For example, a value of "Bearer", as specified in [RFC6750], indicates that the issued security token is a bearer token and the client can simply present it as is without any additional proof of eligibility beyond the contents of the token itself. Note that the meaning of this parameter is different from the meaning of the "issued_token_type" parameter, which declares the representation of the issued security token; the term "token type" is more typically used with the aforementioned meaning as the structural or syntactical representation of the security token, as it is in all "*_token_type" parameters in this specification. If the issued token is not an access token or usable as an access token, then the "token_type" value "N_A" is used to indicate that an OAuth 2.0 "token_type" identifier is not applicable in that context. expires_in RECOMMENDED. The validity lifetime, in seconds, of the token issued by the authorization server. Oftentimes the client will not have the inclination or capability to inspect the content of the token and this parameter provides a consistent and token-type- agnostic indication of how long the token can be expected to be valid. For example, the value 1800 denotes that the token will expire in thirty minutes from the time the response was generated. scope OPTIONAL, if the scope of the issued security token is identical to the scope requested by the client; otherwise, REQUIRED. Jones, et al. Expires January 7, 2020 [Page 10] Internet-Draft OAuth 2.0 Token Exchange July 2019 refresh_token OPTIONAL. A refresh token will typically not be issued when the exchange is of one temporary credential (the subject_token) for a different temporary credential (the issued token) for use in some other context. A refresh token can be issued in cases where the client of the token exchange needs the ability to access a resource even when the original credential is no longer valid (e.g., user-not-present or offline scenarios where there is no longer any user entertaining an active session with the client). Profiles or deployments of this specification should clearly document the conditions under which a client should expect a refresh token in response to "urn:ietf:params:oauth:grant- type:token-exchange" grant type requests. 2.2.2. Error Response If the request itself is not valid or if either the "subject_token" or "actor_token" are invalid for any reason, or are unacceptable based on policy, the authorization server MUST construct an error response, as specified in Section 5.2 of [RFC6749]. The value of the "error" parameter MUST be the "invalid_request" error code. If the authorization server is unwilling or unable to issue a token for all the target services indicated by the "resource" or "audience" parameters, the "invalid_target" error code SHOULD be used in the error response. The authorization server MAY include additional information regarding the reasons for the error using the "error_description" as discussed in Section 5.2 of [RFC6749]. Other error codes may also be used, as appropriate. 2.3. Example Token Exchange The following example demonstrates a hypothetical token exchange in which an OAuth resource server assumes the role of the client during the exchange. It trades an access token, which it received in a protected resource request, for a new token that it will use to call to a backend service (extra line breaks and indentation in the examples are for display purposes only). The resource server receives the following request containing an OAuth access token in the Authorization request header, as specified in Section 2.1 of [RFC6750]. Jones, et al. Expires January 7, 2020 [Page 11] Internet-Draft OAuth 2.0 Token Exchange July 2019 GET /resource HTTP/1.1 Host: frontend.example.com Authorization: Bearer accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC Figure 1: Protected Resource Request The resource server assumes the role of the client for the token exchange and the access token from the request above is sent to the authorization server using a request as specified in Section 2.1. The value of the "subject_token" parameter carries the access token and the value of the "subject_token_type" parameter indicates that it is an OAuth 2.0 access token. The resource server, acting in the role of the client, uses its identifier and secret to authenticate to the authorization server using the HTTP Basic authentication scheme. The "resource" parameter indicates the location of the backend service, https://backend.example.com/api, where the issued token will be used. 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 Figure 2: Token Exchange Request The authorization server validates the client credentials and the "subject_token" presented in the token exchange request. From the "resource" parameter, the authorization server is able to determine the appropriate policy to apply to the request and issues a token suitable for use at https://backend.example.com. The "access_token" parameter of the response contains the new token, which is itself a bearer OAuth access token that is valid for one minute. The token happens to be a JWT; however, its structure and format are opaque to the client so the "issued_token_type" indicates only that it is an access token. Jones, et al. Expires January 7, 2020 [Page 12] Internet-Draft OAuth 2.0 Token Exchange July 2019 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 } Figure 3: Token Exchange Response The resource server can then use the newly acquired access token in making a request to the backend server. GET /api HTTP/1.1 Host: backend.example.com Authorization: Bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQ iOiJodHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2 FzLmV4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1M zMsInN1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQe dw6rxf59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIW vmDCMy5-kdXjwhw Figure 4: Backend Protected Resource Request Additional examples can be found in Appendix A. 3. Token Type Identifiers Several parameters in this specification utilize an identifier as the value to describe the token in question. Specifically, they are the "requested_token_type", "subject_token_type", "actor_token_type" parameters of the request and the "issued_token_type" member of the response. Token type identifiers are URIs. Token Exchange can work with both tokens issued by other parties and tokens from the given authorization server. For the former the token type identifier indicates the syntax (e.g., JWT or SAML 2.0) so the authorization server can parse it; for the latter it indicates what the given authorization server issued it for (e.g., access_token or refresh_token). Jones, et al. Expires January 7, 2020 [Page 13] Internet-Draft OAuth 2.0 Token Exchange July 2019 The following token type identifiers are defined by this specification. Other URIs MAY be used to indicate other token types. urn:ietf:params:oauth:token-type:access_token Indicates that the token is an OAuth 2.0 access token issued by the given authorization server. urn:ietf:params:oauth:token-type:refresh_token Indicates that the token is an OAuth 2.0 refresh token issued by the given authorization server. urn:ietf:params:oauth:token-type:id_token Indicates that the token is an ID Token, as defined in Section 2 of [OpenID.Core]. urn:ietf:params:oauth:token-type:saml1 Indicates that the token is a base64url-encoded SAML 1.1 [OASIS.saml-core-1.1] assertion. urn:ietf:params:oauth:token-type:saml2 Indicates that the token is a base64url-encoded SAML 2.0 [OASIS.saml-core-2.0-os] assertion. The value "urn:ietf:params:oauth:token-type:jwt", which is defined in Section 9 of [JWT], indicates that the token is a JWT. The distinction between an access token and a JWT is subtle. An access token represents a delegated authorization decision, whereas JWT is a token format. An access token can be formatted as a JWT but doesn't necessarily have to be. And a JWT might well be an access token but not all JWTs are access tokens. The intent of this specification is that "urn:ietf:params:oauth:token-type:access_token" be an indicator that the token is a typical OAuth access token issued by the authorization server in question, opaque to the client, and usable the same manner as any other access token obtained from that authorization server. (It could well be a JWT, but the client isn't and needn't be aware of that fact.) Whereas, "urn:ietf:params:oauth:token-type:jwt" is to indicate specifically that a JWT is being requested or sent (perhaps in a cross-domain use- case where the JWT is used as an authorization grant to obtain an access token from a different authorization server as is facilitated by [RFC7523]). Note that for tokens which are binary in nature, the URI used for conveying them needs to be associated with the semantics of a base64 or other encoding suitable for usage with HTTP and OAuth. Jones, et al. Expires January 7, 2020 [Page 14] Internet-Draft OAuth 2.0 Token Exchange July 2019 4. JSON Web Token Claims and Introspection Response Parameters It is useful to have defined mechanisms to express delegation within a token as well as to express authorization to delegate or impersonate. Although the token exchange protocol described herein can be used with any type of token, this section defines claims to express such semantics specifically for JWTs and in an OAuth 2.0 Token Introspection [RFC7662] response. Similar definitions for other types of tokens are possible but beyond the scope of this specification. Note that the claims not established herein but used in examples and descriptions, such as "iss", "sub", "exp", etc., are defined by [JWT]. 4.1. "act" (Actor) Claim The "act" (actor) claim provides a means within a JWT to express that delegation has occurred and identify the acting party to whom authority has been delegated. The "act" claim value is a JSON object and members in the JSON object are claims that identify the actor. The claims that make up the "act" claim identify and possibly provide additional information about the actor. For example, the combination of the two claims "iss" and "sub" might be necessary to uniquely identify an actor. However, claims within the "act" claim pertain only to the identity of the actor and are not relevant to the validity of the containing JWT in the same manner as the top-level claims. Consequently, non- identity claims (e.g., "exp", "nbf", and "aud") are not meaningful when used within an "act" claim, and therefore must not be used. Jones, et al. Expires January 7, 2020 [Page 15] Internet-Draft OAuth 2.0 Token Exchange July 2019 The following example illustrates the "act" (actor) claim within a JWT Claims Set. The claims of the token itself are about user@example.com while the "act" claim indicates that admin@example.com is the current actor. { "aud":"https://consumer.example.com", "iss":"https://issuer.example.com", "exp":1443904177, "nbf":1443904077, "sub":"user@example.com", "act": { "sub":"admin@example.com" } } Figure 5: Actor Claim A chain of delegation can be expressed by nesting one "act" claim within another. The outermost "act" claim represents the current actor while nested "act" claims represent prior actors. The least recent actor is the most deeply nested. The nested "act" claims serve as a history trail that connects the initial request and subject through the various delegation steps undertaken before reaching the current actor. In this sense, the current actor is considered to include the entire authorization/delegation history, leading naturally to the nested structure described here. For the purpose of applying access control policy, the consumer of a token MUST only consider the token's top-level claims and the party identified as the current actor by the "act" claim. Prior actors identified by any nested "act" claims are informational only and are not to be considered in access control decisions. Jones, et al. Expires January 7, 2020 [Page 16] Internet-Draft OAuth 2.0 Token Exchange July 2019 The following example illustrates nested "act" (actor) claims within a JWT Claims Set. The claims of the token itself are about user@example.com while the "act" claim indicates that the system https://service16.example.com is the current actor and https://service77.example.com was a prior actor. Such a token might come about as the result of service16 receiving a token in a call from service77 and exchanging it for a token suitable to call service26 while the authorization server notes the situation in the newly issued token. { "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", } } } Figure 6: Nested Actor Claim When included as a top-level member of an OAuth token introspection response, "act" has the same semantics and format as the claim of the same name. 4.2. "scope" (Scopes) Claim The value of the "scope" claim is a JSON string containing a space- separated list of scopes associated with the token, in the format described in Section 3.3 of [RFC6749]. Jones, et al. Expires January 7, 2020 [Page 17] Internet-Draft OAuth 2.0 Token Exchange July 2019 The following example illustrates the "scope" claim within a JWT Claims Set. { "aud":"https://consumer.example.com", "iss":"https://issuer.example.com", "exp":1443904177, "nbf":1443904077, "sub":"dgaf4mvfs75Fci_FL3heQA", "scope":"email profile phone address" } Figure 7: Scopes Claim OAuth 2.0 Token Introspection [RFC7662] already defines the "scope" parameter to convey the scopes associated with the token. 4.3. "client_id" (Client Identifier) Claim The "client_id" claim carries the client identifier of the OAuth 2.0 [RFC6749] client that requested the token. The following example illustrates the "client_id" claim within a JWT Claims Set indicating an OAuth 2.0 client with "s6BhdRkqt3" as its identifier. { "aud":"https://consumer.example.com", "iss":"https://issuer.example.com", "exp":1443904177, "sub":"user@example.com", "client_id":"s6BhdRkqt3" } Figure 8: Client Identifier Claim OAuth 2.0 Token Introspection [RFC7662] already defines the "client_id" parameter as the client identifier for the OAuth 2.0 client that requested the token. 4.4. "may_act" (Authorized Actor) Claim The "may_act" claim makes a statement that one party is authorized to become the actor and act on behalf of another party. The claim might be used, for example, when a "subject_token" is presented to the token endpoint in a token exchange request and "may_act" claim in the subject token can be used by the authorization server to determine whether the client (or party identified in the "actor_token") is Jones, et al. Expires January 7, 2020 [Page 18] Internet-Draft OAuth 2.0 Token Exchange July 2019 authorized to engage in the requested delegation or impersonation. The claim value is a JSON object and members in the JSON object are claims that identify the party that is asserted as being eligible to act for the party identified by the JWT containing the claim. The claims that make up the "may_act" claim identify and possibly provide additional information about the authorized actor. For example, the combination of the two claims "iss" and "sub" are sometimes necessary to uniquely identify an authorized actor, while the "email" claim might be used to provide additional useful information about that party. However, claims within the "may_act" claim pertain only to the identity of that party and are not relevant to the validity of the containing JWT in the same manner as top-level claims. Consequently, claims such as "exp", "nbf", and "aud" are not meaningful when used within a "may_act" claim, and therefore should not be used. The following example illustrates the "may_act" claim within a JWT Claims Set. The claims of the token itself are about user@example.com while the "may_act" claim indicates that admin@example.com is authorized to act on behalf of 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" } } Figure 9: Authorized Actor Claim When included as a top-level member of an OAuth token introspection response, "may_act" has the same semantics and format as the claim of the same name. 5. Security Considerations Much of the guidance from Section 10 of [RFC6749], the Security Considerations in The OAuth 2.0 Authorization Framework, is also applicable here. Furthermore, [RFC6819] provides additional security considerations for OAuth and [I-D.ietf-oauth-security-topics] has updated security guidance based on deployment experience and new threats that have emerged since OAuth 2.0 was originally published. Jones, et al. Expires January 7, 2020 [Page 19] Internet-Draft OAuth 2.0 Token Exchange July 2019 All of the normal security issues that are discussed in [JWT], especially in relationship to comparing URIs and dealing with unrecognized values, also apply here. In addition, both delegation and impersonation introduce unique security issues. Any time one principal is delegated the rights of another principal, the potential for abuse is a concern. The use of the "scope" claim is suggested to mitigate potential for such abuse, as it restricts the contexts in which the delegated rights can be exercised. 6. Privacy Considerations Tokens employed in the context of the functionality described herein may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties, MUST only be transmitted over encrypted channels, such as Transport Layer Security (TLS). In cases where it is desirable to prevent disclosure of certain information to the client, the token MUST be encrypted to its intended recipient. Deployments SHOULD determine the minimally necessary amount of data and only include such information in issued tokens. In some cases, data minimization may include representing only an anonymous or pseudonymous user. 7. IANA Considerations 7.1. OAuth URI Registration This specification registers the following values in the IANA "OAuth URI" registry [IANA.OAuth.Parameters] established by [RFC6755]. 7.1.1. Registry Contents o URN: urn:ietf:params:oauth:grant-type:token-exchange o Common Name: Token exchange grant type for OAuth 2.0 o Change controller: IESG o Specification Document: Section 2.1 of [[ this specification ]] o URN: urn:ietf:params:oauth:token-type:access_token o Common Name: Token type URI for an OAuth 2.0 access token o Change controller: IESG o Specification Document: Section 3 of [[this specification]] o URN: urn:ietf:params:oauth:token-type:refresh_token o Common Name: Token type URI for an OAuth 2.0 refresh token o Change controller: IESG o Specification Document: Section 3 of [[this specification]] Jones, et al. Expires January 7, 2020 [Page 20] Internet-Draft OAuth 2.0 Token Exchange July 2019 o URN: urn:ietf:params:oauth:token-type:id_token o Common Name: Token type URI for an ID Token o Change controller: IESG o Specification Document: Section 3 of [[this specification]] o URN: urn:ietf:params:oauth:token-type:saml1 o Common Name: Token type URI for a base64url-encoded SAML 1.1 assertion o Change Controller: IESG o Specification Document: Section 3 of [[this specification]] o URN: urn:ietf:params:oauth:token-type:saml2 o Common Name: Token type URI for a base64url-encoded SAML 2.0 assertion o Change Controller: IESG o Specification Document: Section 3 of [[this specification]] 7.2. OAuth Parameters Registration This specification registers the following values in the IANA "OAuth Parameters" registry [IANA.OAuth.Parameters] established by [RFC6749]. 7.2.1. Registry Contents o Parameter name: resource o Parameter usage location: token request o Change controller: IESG o Specification document(s): Section 2.1 of [[ this specification ]] o Parameter name: audience o Parameter usage location: token request o Change controller: IESG o Specification document(s): Section 2.1 of [[ this specification ]] o Parameter name: requested_token_type o Parameter usage location: token request o Change controller: IESG o Specification document(s): Section 2.1 of [[ this specification ]] o Parameter name: subject_token o Parameter usage location: token request o Change controller: IESG o Specification document(s): Section 2.1 of [[ this specification ]] o Parameter name: subject_token_type o Parameter usage location: token request o Change controller: IESG Jones, et al. Expires January 7, 2020 [Page 21] Internet-Draft OAuth 2.0 Token Exchange July 2019 o Specification document(s): Section 2.1 of [[ this specification ]] o Parameter name: actor_token o Parameter usage location: token request o Change controller: IESG o Specification document(s): Section 2.1 of [[ this specification ]] o Parameter name: actor_token_type o Parameter usage location: token request o Change controller: IESG o Specification document(s): Section 2.1 of [[ this specification ]] o Parameter name: issued_token_type o Parameter usage location: token response o Change controller: IESG o Specification document(s): Section 2.2.1 of [[ this specification ]] 7.3. OAuth Access Token Type Registration This specification registers the following access token type in the IANA "OAuth Access Token Types" registry [IANA.OAuth.Parameters] established by [RFC6749]. 7.3.1. Registry Contents o Type name: N_A o Additional Token Endpoint Response Parameters: (none) o HTTP Authentication Scheme(s): (none) o Change controller: IESG o Specification document(s): Section 2.2.1 of [[ this specification ]] 7.4. JSON Web Token Claims Registration This specification registers the following Claims in the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims] established by [JWT]. 7.4.1. Registry Contents o Claim Name: "act" o Claim Description: Actor o Change Controller: IESG o Specification Document(s): Section 4.1 of [[ this specification ]] o Claim Name: "scope" o Claim Description: Scope Values o Change Controller: IESG Jones, et al. Expires January 7, 2020 [Page 22] Internet-Draft OAuth 2.0 Token Exchange July 2019 o Specification Document(s): Section 4.2 of [[ this specification ]] o Claim Name: "client_id" o Claim Description: Client Identifier o Change Controller: IESG o Specification Document(s): Section 4.3 of [[ this specification ]] o Claim Name: "may_act" o Claim Description: Authorized Actor - the party that is authorized to become the actor o Change Controller: IESG o Specification Document(s): Section 4.4 of [[ this specification ]] 7.5. OAuth Token Introspection Response Registration This specification registers the following values in the IANA "OAuth Token Introspection Response" registry [IANA.OAuth.Parameters] established by [RFC7662]. 7.5.1. Registry Contents o Claim Name: "act" o Claim Description: Actor o Change Controller: IESG o Specification Document(s): Section 4.1 of [[ this specification ]] o Claim Name: "may_act" o Claim Description: Authorized Actor - the party that is authorized to become the actor o Change Controller: IESG o Specification Document(s): Section 4.4 of [[ this specification ]] 7.6. OAuth Extensions Error Registration This specification registers the following values in the IANA "OAuth Extensions Error" registry [IANA.OAuth.Parameters] established by [RFC6749]. 7.6.1. Registry Contents o Error Name: "invalid_target" o Error Usage Location: token error response o Related Protocol Extension: OAuth 2.0 Token Exchange o Change Controller: IETF o Specification Document(s): Section 2.2.2 of [[ this specification ]] Jones, et al. Expires January 7, 2020 [Page 23] Internet-Draft OAuth 2.0 Token Exchange July 2019 8. References 8.1. Normative References [IANA.JWT.Claims] IANA, "JSON Web Token Claims", . [IANA.OAuth.Parameters] IANA, "OAuth Parameters", . [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . 8.2. Informative References [I-D.ietf-oauth-security-topics] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "OAuth 2.0 Security Best Current Practice", draft-ietf- oauth-security-topics-12 (work in progress), March 2019. Jones, et al. Expires January 7, 2020 [Page 24] Internet-Draft OAuth 2.0 Token Exchange July 2019 [OASIS.saml-core-1.1] Maler, E., Mishra, P., and R. Philpott, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1", OASIS Standard oasis-sstc-saml-core-1.1, September 2003. [OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core- 2.0-os, March 2005. [OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, . [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, . [RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, May 2015, . [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Jones, et al. Expires January 7, 2020 [Page 25] Internet-Draft OAuth 2.0 Token Exchange July 2019 [WS-Trust] Nadalin, A., Goodner, M., Gudgin, M., Barbir, A., and H. Granqvist, "WS-Trust 1.4", February 2012, . Appendix A. Additional Token Exchange Examples Two example token exchanges are provided in the following sections illustrating impersonation and delegation, respectively (with extra line breaks and indentation for display purposes only). A.1. Impersonation Token Exchange Example A.1.1. Token Exchange Request In the following token exchange request, a client is requesting a token with impersonation semantics (with only a "subject_token" and no "actor_token", delegation is impossible). The client tells the authorization server that it needs a token for use at the target service with the logical name "urn:example:cooperation-context". 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 Figure 10: Token Exchange Request A.1.2. Subject Token Claims The "subject_token" in the prior request is a JWT and the decoded JWT Claims Set is shown here. The JWT is intended for consumption by the authorization server within a specific time window. The subject of the JWT ("bdc@example.net") is the party on behalf of whom the new token is being requested. Jones, et al. Expires January 7, 2020 [Page 26] Internet-Draft OAuth 2.0 Token Exchange July 2019 { "aud":"https://as.example.com", "iss":"https://original-issuer.example.net", "exp":1441910600, "nbf":1441909000, "sub":"bdc@example.net", "scope":"orders profile history" } Figure 11: Subject Token Claims A.1.3. Token Exchange Response The "access_token" parameter of the token exchange response shown below contains the new token that the client requested. The other parameters of the response indicate that the token is a bearer access token that expires in an hour. 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 } Figure 12: Token Exchange Response A.1.4. Issued Token Claims The decoded JWT Claims Set of the issued token is shown below. The new JWT is issued by the authorization server and intended for consumption by a system entity known by the logical name "urn:example:cooperation-context" any time before its expiration. The subject ("sub") of the JWT is the same as the subject the token used to make the request, which effectively enables the client to impersonate that subject at the system entity known by the logical name of "urn:example:cooperation-context" by using the token. Jones, et al. Expires January 7, 2020 [Page 27] Internet-Draft OAuth 2.0 Token Exchange July 2019 { "aud":"urn:example:cooperation-context", "iss":"https://as.example.com", "exp":1441913610, "sub":"bdc@example.net", "scope":"orders profile history" } Figure 13: Issued Token Claims A.2. Delegation Token Exchange Example A.2.1. Token Exchange Request In the following token exchange request, a client is requesting a token and providing both a "subject_token" and an "actor_token". The client tells the authorization server that it needs a token for use at the target service with the logical name "urn:example:cooperation- context". Policy at the authorization server dictates that the issued token be a composite. 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 Figure 14: Token Exchange Request A.2.2. Subject Token Claims The "subject_token" in the prior request is a JWT and the decoded JWT Claims Set is shown here. The JWT is intended for consumption by the authorization server before a specific expiration time. The subject Jones, et al. Expires January 7, 2020 [Page 28] Internet-Draft OAuth 2.0 Token Exchange July 2019 of the JWT ("user@example.net") is the party on behalf of whom the new token is being requested. { "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" } } Figure 15: Subject Token Claims A.2.3. Actor Token Claims The "actor_token" in the prior request is a JWT and the decoded JWT Claims Set is shown here. This JWT is also intended for consumption by the authorization server before a specific expiration time. The subject of the JWT ("admin@example.net") is the actor that will wield the security token being requested. { "aud":"https://as.example.com", "iss":"https://original-issuer.example.net", "exp":1441910060, "sub":"admin@example.net" } Figure 16: Actor Token Claims A.2.4. Token Exchange Response The "access_token" parameter of the token exchange response shown below contains the new token that the client requested. The other parameters of the response indicate that the token is a JWT that expires in an hour and that the access token type is not applicable since the issued token is not an access token. Jones, et al. Expires January 7, 2020 [Page 29] Internet-Draft OAuth 2.0 Token Exchange July 2019 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 } Figure 17: Token Exchange Response A.2.5. Issued Token Claims The decoded JWT Claims Set of the issued token is shown below. The new JWT is issued by the authorization server and intended for consumption by a system entity known by the logical name "urn:example:cooperation-context" any time before its expiration. The subject ("sub") of the JWT is the same as the subject of the "subject_token" used to make the request. The actor ("act") of the JWT is the same as the subject of the "actor_token" used to make the request. This indicates delegation and identifies "admin@example.net" as the current actor to whom authority has been delegated to act on behalf of "user@example.net". { "aud":"urn:example:cooperation-context", "iss":"https://as.example.com", "exp":1441913610, "scope":"status feed", "sub":"user@example.net", "act": { "sub":"admin@example.net" } } Figure 18: Issued Token Claims Jones, et al. Expires January 7, 2020 [Page 30] Internet-Draft OAuth 2.0 Token Exchange July 2019 Appendix B. Acknowledgements This specification was developed within the OAuth Working Group, which includes dozens of active and dedicated participants. It was produced under the chairmanship of Hannes Tschofenig, Derek Atkins, and Rifaat Shekh-Yusef with Kathleen Moriarty, Stephen Farrell, Eric Rescorla, Roman Danyliw, and Benjamin Kaduk serving as Security Area Directors. The following individuals contributed ideas, feedback, and wording to this specification: Caleb Baker, Vittorio Bertocci, Mike Brown, Thomas Broyer, William Denniss, Vladimir Dzhuvinov, Phil Hunt, Benjamin Kaduk, Jason Keglovitz, Torsten Lodderstedt, Adam Lewis, James Manger, Nov Matake, Matt Miller, Hilarie Orman, Matthew Perry, Eric Rescorla, Justin Richer, Adam Roach, Rifaat Shekh-Yusef, Scott Tomilson, and Hannes Tschofenig. Appendix C. Document History [[ to be removed by the RFC Editor before publication as an RFC ]] -18 o -17 o Editorial improvements and example fixes resulting from IESG evaluation comments. o Added a pointer to RFC6749's Appendix B. on the "Use of application/x-www-form-urlencoded Media Type" as a way of providing a normative citation (by reference) for the media type. o Strengthened some of the wording in the privacy considerations to bring it inline with RFC 7519 Sec. 12 and RFC 6749 Sec. 10.8. -16 o Fixed typo and added an AD to Acknowledgements. -15 o Updated the nested actor claim example to (hopefully) be more straightforward. o Reworked Privacy Considerations to say to use TLS in transit, minimize the amount of information in the token, and encrypt the token if disclosure of its information to the client is a concern per https://mailarchive.ietf.org/arch/msg/secdir/ KJhx4aq_U5uk3k6zpYP-CEHbpVM Jones, et al. Expires January 7, 2020 [Page 31] Internet-Draft OAuth 2.0 Token Exchange July 2019 o Moved the Security and Privacy Considerations sections to before the IANA Considerations. -14 o Added text in Section 4.1 about the "act" claim stating that only the top-level claims and the current actor are to be considered in applying access control decisions. -13 o Updated the claim name and value syntax for scope to be consistent with the treatment of scope in RFC 7662 OAuth 2.0 Token Introspection. o Updated the client identifier claim name to be consistent with the treatment of client id in RFC 7662 OAuth 2.0 Token Introspection. -12 o Updated to use the boilerplate from RFC 8174. -11 o Added new WG chair and AD to the Acknowledgements. o Applied clarifications suggested during AD review by EKR. -10 o Defined token type URIs for base64url-encoded SAML 1.1 and SAML 2.0 assertions. o Applied editorial fixes. -09 o Changed "security tokens obtained could be used in a number of contexts" to "security tokens obtained may be used in a number of contexts" per a WGLC suggestion. o Clarified that the validity of the subject or actor token have no impact on the validity of the issued token after the exchange has occurred per a WGLC comment. o Changed use of invalid_target error code to a SHOULD per a WGLC comment. o Clarified text about non-identity claims within the "act" claim being meaningless per a WGLC comment. o Added brief Privacy Considerations section per WGLC comments. -08 Jones, et al. Expires January 7, 2020 [Page 32] Internet-Draft OAuth 2.0 Token Exchange July 2019 o Use the bibxml reference for OpenID.Core rather than defining it inline. o Added editor role for Campbell. o Minor clarification of the text for actor_token. -07 o Fixed typo (desecration -> discretion). o Added an explanation of the relationship between scope, audience and resource in the request and added an "invalid_target" error code enabling the AS to tell the client that the requested audiences/resources were too broad. -06 o Drop "An STS for the REST of Us" from the title. o Drop "heavyweight" and "lightweight" from the abstract and introduction. o Clarifications on the language around xxxxxx_token_type. o Remove the want_composite parameter. o Add a short mention of proof-of-possession style tokens to the introduction and remove the respective open issue. -05 o Defined the JWT claim "cid" to express the OAuth 2.0 client identifier of the client that requested the token. o Defined and requested registration for "act" and "may_act" as Token introspection response parameters (in addition to being JWT claims). o Loosen up the language about refresh_token in the response to OPTIONAL from NOT RECOMMENDED based on feedback form real world deployment experience. o Add clarifying text about the distinction between JWT and access token URIs. o Close out (remove) some of the Open Issues bullets that have been resolved. -04 o Clarified that the "resource" and "audience" request parameters can be used at the same time (via http://www.ietf.org/mail- archive/web/oauth/current/msg15335.html). o Clarified subject/actor token validity after token exchange and explained a bit more about the recommendation to not issue refresh tokens (via http://www.ietf.org/mail-archive/web/oauth/current/ msg15318.html). Jones, et al. Expires January 7, 2020 [Page 33] Internet-Draft OAuth 2.0 Token Exchange July 2019 o Updated the examples appendix to use an issuer value that doesn't imply that the client issued and signed the tokens and used "Bearer" and "urn:ietf:params:oauth:token-type:access_token" in one of the responses (via http://www.ietf.org/mail- archive/web/oauth/current/msg15335.html). o Defined and registered urn:ietf:params:oauth:token-type:id_token, since some use cases perform token exchanges for ID Tokens and no URI to indicate that a token is an ID Token had previously been defined. -03 o Updated the document editors (adding Campbell, Bradley, and Mortimore). o Added to the title. o Added to the abstract and introduction. o Updated the format of the request to use application/x-www-form- urlencoded request parameters and the response to use the existing token endpoint JSON parameters defined in OAuth 2.0. o Changed the grant type identifier to urn:ietf:params:oauth:grant- type:token-exchange. o Added RFC 6755 registration requests for urn:ietf:params:oauth:token-type:refresh_token, urn:ietf:params:oauth:token-type:access_token, and urn:ietf:params:oauth:grant-type:token-exchange. o Added RFC 6749 registration requests for request/response parameters. o Removed the Implementation Considerations and the requirement to support JWTs. o Clarified many aspects of the text. o Changed "on_behalf_of" to "subject_token", "on_behalf_of_token_type" to "subject_token_type", "act_as" to "actor_token", and "act_as_token_type" to "actor_token_type". o Added an "audience" request parameter used to indicate the logical names of the target services at which the client intends to use the requested security token. o Added a "want_composite" request parameter used to indicate the desire for a composite token rather than trying to infer it from the presence/absence of token(s) in the request. o Added a "resource" request parameter used to indicate the URLs of resources at which the client intends to use the requested security token. o Specified that multiple "audience" and "resource" request parameter values may be used. o Defined the JWT claim "act" (actor) to express the current actor or delegation principal. o Defined the JWT claim "may_act" to express that one party is authorized to act on behalf of another party. Jones, et al. Expires January 7, 2020 [Page 34] Internet-Draft OAuth 2.0 Token Exchange July 2019 o Defined the JWT claim "scp" (scopes) to express OAuth 2.0 scope- token values. o Added the "N_A" (not applicable) OAuth Access Token Type definition for use in contexts in which the token exchange syntax requires a "token_type" value, but in which the token being issued is not an access token. o Added examples. -02 o Enabled use of Security Token types other than JWTs for "act_as" and "on_behalf_of" request values. o Referenced the JWT and OAuth Assertions RFCs. -01 o Updated references. -00 o Created initial working group draft from draft-jones-oauth-token- exchange-01. Authors' Addresses Michael B. Jones Microsoft Email: mbj@microsoft.com URI: http://self-issued.info/ Anthony Nadalin Microsoft Email: tonynad@microsoft.com Brian Campbell (editor) Ping Identity Email: brian.d.campbell@gmail.com John Bradley Yubico Email: ve7jtb@ve7jtb.com Jones, et al. Expires January 7, 2020 [Page 35] Internet-Draft OAuth 2.0 Token Exchange July 2019 Chuck Mortimore Salesforce Email: cmortimore@salesforce.com Jones, et al. Expires January 7, 2020 [Page 36]