OAuth Identity Chaining

Introduction The Mutual TLS Profile for OAuth 2.0 specification states that when a client authenticates to the token endpoint of an authorization server using mTLS, the confirmation ("cnf") claim in the returned token is populated with the SHA-256 thumbprint of the client's X.509 certificate when the authorization server issues sender constrained tokens. This document defines a new OAuth claim, "chained_id", that allows a client to pass the "client_id" and "cnf" values for a different OAuth client in a token request. The authorization server uses the values in the "chained_id" claim to populate the "client_id" and "cnf" claims in the returned access token instead of those of the requesting client.

Conventions and Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 . This specification uses the terms "Access Token", "Authorization Server", "Client", "Protected Resource", "Resource Server", and "Token Endpoint" defined by OAuth 2.0 , the term "Assertion" defined by , the term "Token Endpoint" defined by , the term "Token Exchange" defined by , and the terms defined by OpenID Connect Core 1.0 .

Use Case The primary use case is a situation where a protected resource (PR1) may need to call a second protected resource (PR2) in a different ICAM ecosystem to satisfy a query received from a client. PR1 cannot simply relay the token, Token 1, it received from the client to PR2 since PR2 trusts a different authorization server (AS2). Also, when PR1 presents its token to PR2, we want PR2 to be able to make authorization decisions based on PR1's identity as asserted by the "client_id" and "cnf" fields in the token. Before presenting the proposed solution, we state some assumptions used in this use case. The first is that OAuth clients authenticate to authorization servers using mTLS which allows the authorization servers to sender constrain tokens by populating a "cnf" field in issued tokens. The second is that protected resources make authorization decisions based upon certain claims that identify the client presenting the token. The method proposed in this specification that enables PR1 to obtain a sender constrained token that contains PR1 identity information necessary for authorization decisions at PR2 is as follows and is shown in . PR1 performs token exchange with its authorization server (AS1) to exchange Token 1 for a second token, Token 2, that is valid at PR2 and contains the identity information for PR1. However, when AS1 receives the token exchange request from PR1, AS1 does not generate the token, Token 2, that is returned to PR1 to complete the token exchange request. Instead, AS1 generates a JWT assertion and, acting as an OAuth client, issues an assertion grant request to AS2 using the generated JWT assertion. AS2 then generates Token 2, returns it to AS1 to complete the assertion grant request, and AS1 returns Token 2 to PR1 to complete the token exchange request. Under normal circumstances, AS2 will populate the "client_id" and "cnf" fields with the values for AS1 since it, acting as an OAuth client, issued the assertion grant request to AS2. We define a new OAuth parameter in the next section to allow AS2 to populate these fields with the values for PR1 so Token 2 will pass the authorization checks at PR2.

Token Exchange Protocol Flow when AS2 Generates Token 2 | | |Client|-(1)-Token 1->|PR1| |PR2| | | | | | | +------+ +---+ +---+ | ^ (2) Token Exchange | | Request | | | | (6) Return | | Token 2 v | +---+ +---+ (3) Generate | |--(4)-JWT Assertion-->| | JWT Assertion |AS1| Grant Request |AS2| | |<-----(5)-Token 2-----| | +---+ +---+ ]]>

"chained_id" Claim The "chained_id" claim value in a token request is a JSON object that contains claims about an OAuth client that is different from a proxying OAuth client making the token request. For the use case described in , the requesting client (AS1) includes the "client_id" and "cnf" claims of a different client (PR1) in a "chained_id" claim in the request. If the proxying client (AS1) making the request is registered with the authorization server (AS2), the authorization server (AS2) populates the "client_id" and "cnf" claims in the returned access token with the values in the "chained_id" claim in the request (those identifying PR1) instead of those of the proxying client making the request (AS1).

Non-normative Example The following is a non-normative example using the example in Where AS1 makes an assertion grant request to AS2 on behalf of PR1. In the example, "A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0" is the hash of PR1's X.509 certificate. When AS1 receives a token exchange request from PR1, it generates a JWT assertion that includes a "chained_id" claim that identifies PR1 in the "client_id" and "cnf" sub-claims.

Example JWT Assertion Using the chained_id claim When AS2 receives the assertion grant request from AS1, it populates the fields of a token that includes PR1's values in the "client_id" and "cnf" fields and returns the token to AS1.

Token returned by AS2 to AS1 for PR1 AS1 returns the token to PR1 to complete the token exchange request.

Security Considerations To ensure the proxying OAuth client requesting the second token (AS1) is trusted by the authorization server generating the second token (AS2) to make token requests that include a "chained_id" claim, we assume that AS1 has a pre-existing trust relationship with AS2.