Internet-Draft OAuth Identity Chaining November 2022
Jenkins & Burgin Expires 12 May 2023 [Page]
OAuth Working Group
Intended Status:
Standards Track
M. Jenkins
National Security Agency
K. Burgin

OAuth Identity Chaining


This specification defines a new OAuth claim that allows a proxying OAuth client to pass identity information for a different OAuth client to an OAuth authorization server during a token request. The authorization server uses this additional identity information when populating the "client_id" and "cnf" fields of the returned access token instead of the identity information about the proxying client requesting the token.

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

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 12 May 2023.

Table of Contents

1. Introduction

The Mutual TLS Profile for OAuth 2.0 specification [RFC8705] 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.

1.1. 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 [RFC2119].

This specification uses the terms "Access Token", "Authorization Server", "Client", "Protected Resource", "Resource Server", and "Token Endpoint" defined by OAuth 2.0 [RFC6749], the term "Assertion" defined by [RFC7521], the term "Token Endpoint" defined by [RFC7662], the term "Token Exchange" defined by [RFC8693], and the terms defined by OpenID Connect Core 1.0 [OIDC-Core].

2. 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 Figure 1.

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.

                       Org 1                      Org 2

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

Figure 1: Token Exchange Protocol Flow when AS2 Generates Token 2

3. "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 Section 2, 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).

4. Non-normative Example

The following is a non-normative example using the example in Section 2 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.

  "sub": "",
  "aud": "",
  "iss": "",
    "chained_id": {
      "client_id": "",
        "x5t#S256": "A4DtL2JmUMhAsvJj5tKyn64SqzmuXbMrJa0n761y5v0"
Figure 2: 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.

  "client_id: ""
Figure 3: Token returned by AS2 to AS1 for PR1

AS1 returns the token to PR1 to complete the token exchange request.

5. 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.

6. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , <>.
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, , <>.
Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, , <>.
Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, , <>.
Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, , <>.
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <>.
Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, , <>.
OpenID_Foundation, "OpenID Connect Core 1.0 incorporating errata set 1", .

Authors' Addresses

Mike Jenkins
National Security Agency
Kelley Burgin