OpenID Authentication Token Protocol

3.1. Claims

An OAT MUST contain the following claims:¶

iss

REQUIRED. The Issuer Identifier of the OP. It MUST be identical to the iss claim of the Source ID Token.¶

sub

REQUIRED. The subject identifier. Its value is determined by the OP's audience-specific policy (see Section 3.2).¶

aud

REQUIRED. An array of one or more Target Relying Party identifiers to which the OAT is scoped. Even when a single audience is present, using the array form is RECOMMENDED for consistency.¶

exp

REQUIRED. Expiration time. An OAT SHOULD be short-lived.¶

iat

REQUIRED. Time at which the OAT was issued.¶

auth_time

REQUIRED. The auth_time value from the Source ID Token, conveying the time of the original authentication event. It MUST NOT be updated by the exchange.¶

cnf

REQUIRED. A confirmation claim [RFC7800] binding the OAT to a proof-of-possession key. It MUST contain a single jkt member whose value is the base64url-encoded JWK SHA-256 Thumbprint [RFC7638] of the key that the Requesting Client proved possession of, via a DPoP proof, on the token exchange request. The provenance of that key depends on whether the Source ID Token is itself key-bound (see Section 3.3).¶

An OAT SHOULD contain the following claims when they are present in the Source ID Token, preserving the authentication session state:¶

sid

The Session ID from the Source ID Token, tying the OAT to the OP session so that session lifecycle events (for example, logout) can be reflected.¶

acr

The Authentication Context Class Reference from the Source ID Token.¶

amr

The Authentication Methods References from the Source ID Token.¶

An OAT MAY contain the following claims:¶

nbf

The time before which the OAT MUST NOT be accepted.¶

jti

A unique identifier for the OAT, to support replay detection.¶

azp

The Authorized Party. When present, its value is the client identifier of the Requesting Client.¶

act

An actor claim, as defined in Section 4.1 of [RFC8693], whose sub member identifies the Requesting Client that obtained and presents the OAT. Its use is RECOMMENDED so that a Target Relying Party can determine which party mediated the assertion.¶

Any additional identity claims are included only as permitted by the OP's audience-specific policy (see Section 4.4).¶

An OAT MUST NOT be used as an OAuth 2.0 access token, and MUST NOT be accepted by a protected resource in place of an access token.¶

3.2. Subject Identifier

The value of the sub claim in an OAT is deployment- and audience-dependent. An OP MAY issue a public subject identifier (the same value as the Source ID Token's sub) or a pairwise (audience-scoped) subject identifier, according to its policy and the registration of each Target Relying Party.¶

When multiple audiences are requested in a single exchange (see Section 4.1), the OP MUST issue a single OAT containing a single sub value that is valid for all of the requested audiences. If the OP's policy would require different sub values for different requested audiences -- for example, because the requested audiences belong to different pairwise identifier sectors -- the OP MUST NOT issue an OAT and MUST instead return an error as described in Section 4.5.¶

3.3. Key Binding

An OAT is always key-bound. The binding is established by a single, uniform mechanism: the Requesting Client presents a DPoP proof [RFC9449] on the token exchange request, and the OP sets the OAT's cnf claim to the JWK Thumbprint ([RFC7638], expressed as jkt) of the key demonstrated by that proof. The same key is later used by the Requesting Client to demonstrate proof of possession when it presents the OAT to a Target Relying Party (Section 5).¶

The provenance of the binding key differs depending on whether the Source ID Token is itself key-bound, but the mechanism and the resulting cnf form do not:¶

• Key-bound Source ID Token. When the Source ID Token is key-bound as defined in [OpenID.KeyBinding] and therefore carries a cnf claim, the DPoP proof key on the exchange MUST be the key bound by that cnf claim. The OP MUST verify that the proof key's thumbprint matches the Source ID Token's bound key before issuing the OAT. The Requesting Client thus reuses the single key it already holds, minimizing key management, and the OP obtains proof that the Requesting Client legitimately holds the Source ID Token's bound key.¶

• Bearer (non-key-bound) Source ID Token. When the Source ID Token has no cnf claim, the Requesting Client presents a DPoP proof using a key of its own choosing (for example, a stable client key or a fresh per-share key). The OP binds the OAT to that key. This lets a Requesting Client obtain a key-bound OAT even from a bearer Source ID Token; the associated trust considerations are described in Section 7.¶

In both cases the OP normalizes the OAT cnf to the jkt (thumbprint) form regardless of how the Source ID Token expressed its own cnf; the full public key is carried in the DPoP proof at presentation and need not be embedded in the OAT. This keeps the trust model aligned with [OpenID.KeyBinding]: the Requesting Client is the authenticating component that proves possession, and the Target Relying Party is the consuming component that requires such proof.¶

A Target Relying Party MUST NOT trust an OAT bearing a cnf claim without a corresponding, successfully verified proof of possession (see Section 5).¶

4.1. Token Request

The Requesting Client makes a token exchange request to the token endpoint. In addition to authenticating as an OAuth client, the request uses the following parameters:¶

grant_type

REQUIRED. MUST be urn:ietf:params:oauth:grant-type:token-exchange.¶

subject_token

REQUIRED. The Source ID Token.¶

subject_token_type

REQUIRED. MUST be urn:ietf:params:oauth:token-type:id_token.¶

requested_token_type

REQUIRED. MUST be urn:openid:params:token-type:authn-token (Section 8.1).¶

audience

REQUIRED. One or more identifiers of the Target Relying Parties for which the OAT is requested. Multiple audiences MAY be requested by including the audience parameter multiple times, subject to the constraint in Section 3.2.¶

resource

OPTIONAL. One or more absolute URIs, as defined in Section 2.1 of [RFC8693], further indicating the target service(s) at which the OAT is intended to be used.¶

scope

OPTIONAL. The requested scope. Used, together with the claims parameter, by the Requesting Client to indicate the identity claims it wishes the OAT to contain (see Section 4.4).¶

claims

OPTIONAL. A JSON object, as defined in Section 5.5 of [OpenID.Core], requesting specific claims to be included in the OAT. The OP remains authoritative over which claims are released.¶

The Requesting Client MUST include a DPoP proof JWT, as defined in Section 4 of [RFC9449], in the DPoP header field of the token request. The OAT is bound to the key demonstrated by this proof (Section 3.3). When the Source ID Token is key-bound, the proof MUST be made with the key bound by the Source ID Token's cnf claim; otherwise the Requesting Client MAY use a key of its own choosing. The OP MUST verify the DPoP proof as described in Section 4.2.¶

The following is a non-normative example of a token request (line breaks and indentation within the body are for display purposes only):¶

POST /token HTTP/1.1
Host: op.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwia...

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&subject_token=eyJhbGciOiJSUzI1NiIsInR5cCI6ImRwb3AraWRfdG9rZW4i...
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aid_token
&requested_token_type=urn%3Aopenid%3Aparams%3Atoken-type%3Aauthn-token
&audience=https%3A%2F%2Frp-b.example.org
&scope=openid

4.2. Token Endpoint Processing

Upon receiving a token exchange request as defined above, the OP MUST, in addition to its normal client authentication and token exchange processing:¶

1. Validate the Source ID Token per Section 3.1.3.7 of [OpenID.Core], including its signature, issuer, expiration, and integrity. The aud of the Source ID Token identifies the Requesting Client's original client registration; the OP MUST confirm that the authenticated Requesting Client is authorized to exchange that ID Token.¶

2. Verify the DPoP proof in the DPoP header field per Section 5 of [RFC9449]. If the DPoP proof is missing or fails this verification, the OP MUST reject the request with an invalid_dpop_proof error.¶

3. If the Source ID Token contains a cnf claim, additionally confirm that the JWK Thumbprint [RFC7638] of the proof's key equals the thumbprint of the key bound by that cnf claim. If the proof is valid but its key does not match, the OP MUST reject the request with an invalid_key_binding error (Section 4.5).¶

4. Determine, for each requested audience (and any resource), whether the Requesting Client is authorized to obtain an OAT for that Target Relying Party. If any requested audience is not permitted, the OP MUST return an invalid_target error.¶

5. Determine the sub value per Section 3.2. If a single sub value cannot satisfy all requested audiences, return an invalid_target error.¶

6. Determine the set of identity claims to include per Section 4.4.¶

7. Mint the OAT, copying iss, auth_time, and (when present) sid, acr, and amr from the Source ID Token, setting aud to the requested audience(s), setting cnf to { "jkt": <thumbprint of the DPoP proof key> } (Section 3.3), and signing it with the OP's signing key.¶

4.3. Token Response

The response is an OAuth 2.0 Token Exchange response as defined in Section 2.2 of [RFC8693]. The OAT is returned in the access_token response parameter (as required by that specification for the issued token), and the issued_token_type parameter MUST be urn:openid:params:token-type:authn-token.¶

Because the OAT is not an OAuth 2.0 access token, the token_type response parameter MUST be N_A as described in Section 2.2.1 of [RFC8693].¶

The following is a non-normative example response:¶

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

{
  "access_token": "eyJ0eXAiOiJhdXRobitqd3QiLCJhbGciOiJSUzI1NiJ9...",
  "issued_token_type": "urn:openid:params:token-type:authn-token",
  "token_type": "N_A",
  "expires_in": 300
}

The following is the non-normative, decoded payload of the OAT from the response above. The cnf claim carries the jkt thumbprint of the key the Requesting Client proved possession of on the exchange request.¶

{
  "iss": "https://op.example.com",
  "sub": "Z5O3upPC88QrAjx00dis",
  "aud": ["https://rp-b.example.org"],
  "exp": 1749825900,
  "iat": 1749825600,
  "auth_time": 1749820000,
  "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
  "acr": "urn:mace:incommon:iap:silver",
  "amr": ["pwd", "otp"],
  "azp": "s6BhdRkqt3",
  "act": { "sub": "s6BhdRkqt3" },
  "cnf": {
    "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
  }
}

4.4. Claims Minimization

The Requesting Client MAY request identity claims to be included in the OAT using the scope and claims parameters. The OP is authoritative over the claims that are actually released. The OP MUST apply its audience-specific policy and MAY remove any requested claim that the applicable Target Relying Party is not authorized to receive.¶

To prevent over-sharing, an OP SHOULD default to releasing only the authentication and session claims defined in Section 3.1 (namely iss, sub, aud, exp, iat, auth_time, and, when present, sid, acr, amr, and cnf), including additional identity claims only when they are both requested and permitted by policy. An OAT MUST NOT contain any claim that the OP's audience-specific policy does not permit for every audience named in the aud claim.¶

4.5. Error Responses

Errors are returned as defined in Section 2.2.2 of [RFC8693] and Section 5.2 of [RFC6749]. In addition to the error codes defined there, this document relies on the following:¶

invalid_target

The requested audience or resource is unknown, is not permitted for the Requesting Client, or cannot be satisfied by a single subject identifier across all requested audiences (see Section 3.2).¶

invalid_dpop_proof

As defined in Section 7 of [RFC9449]; returned when the required DPoP proof is missing or is not a valid DPoP proof (for example, a malformed proof, an invalid signature, a stale iat, or a replayed jti). This code does not cover the case in which a valid proof is made with the wrong key; see invalid_key_binding.¶

invalid_key_binding

The DPoP proof is itself valid, but the Source ID Token is key-bound and the JWK Thumbprint of the proof key does not match the key bound by the Source ID Token's cnf claim (Section 4.2). This is a non-retryable condition: presenting the same request with a freshly generated proof over the same key will not succeed. This code is registered by this document (Section 8.3).¶

7.1. Key Binding of the OAT

The OAT is always bound, via its cnf claim, to a key held by the Requesting Client rather than by the Target Relying Party. The Requesting Client therefore acts as the authenticating component that proves possession; the Target Relying Party relies on that proof rather than performing proof of possession itself. Deployments MUST ensure that the Requesting Client's private key is protected commensurate with the sensitivity of the authentication assertions it can mint OATs for. As recommended by [OpenID.KeyBinding], a distinct key pair per Requesting Client instance SHOULD be used to avoid token confusion; a Requesting Client MAY additionally use a fresh per-share key when binding an OAT from a bearer Source ID Token.¶

7.2. Bearer versus Key-Bound Source ID Tokens

When the Source ID Token is key-bound, requiring the exchange DPoP proof to be made with the bound key ensures that only a party actually holding that key can obtain an OAT; a stolen bearer copy of a key-bound ID Token cannot be exchanged.¶

When the Source ID Token is a bearer token, this protection is absent: the security of the exchange rests on the confidentiality of the Source ID Token together with the Requesting Client's authentication to the token endpoint. Because token exchange requires the Requesting Client to authenticate as an OAuth client, a stolen bearer Source ID Token alone -- without the client's credentials -- still cannot be exchanged for an OAT. Nonetheless, minting an OAT from a bearer Source ID Token is strictly weaker than from a key-bound one: whichever key the (authenticated) client presents becomes the OAT's bound key. OPs SHOULD prefer key-bound Source ID Tokens, SHOULD require them for security-sensitive audiences, and MAY refuse by policy to mint OATs from bearer Source ID Tokens.¶

7.3. Audience Restriction and Token Confusion

The OAT's aud claim names the Target Relying Party rather than the Requesting Client, giving a conforming Target Relying Party a clear basis to accept the token. The distinct typ value authn+jwt prevents an OAT from being substituted for an ID Token, an access token, or a DPoP-bound ID Token ([OpenID.KeyBinding]). Target Relying Parties MUST strictly enforce the aud, iss, and typ checks in Section 5.¶

7.4. Claims Minimization and Correlation

By defaulting to authentication and session claims and applying audience-specific policy, the OAT limits disclosure of identity claims to what each Target Relying Party is authorized to receive. Where cross-RP correlation is a concern, OPs SHOULD issue pairwise subject identifiers per Section 3.2. Because a single OAT carries a single sub value, naming multiple audiences with incompatible pairwise sectors is rejected rather than silently collapsing them to a shared identifier.¶

7.5. Session State

The auth_time in an OAT describes the original authentication event. Preserving sid allows an OAT's validity to be tied to the OP session so that logout or session termination can be reflected; OPs and Target Relying Parties MAY integrate OAT lifecycle with existing session management and revocation mechanisms.¶

The Source ID Token's nonce claim is not carried into the OAT. The nonce is a request-response correlator between the Requesting Client and the OP; no recipient of the OAT issued it or can validate it for its intended purpose.¶

8.1. Token Type Identifier

The token type identifier urn:openid:params:token-type:authn-token, used as the value of the requested_token_type and issued_token_type parameters, resides in the urn:openid:params URN sub-namespace managed by the OpenID Foundation rather than the IANA "OAuth URI" registry. It is defined here following the conventions for OAuth token type identifiers in Section 4.1 of [RFC8693]. This document requests no IANA action for this identifier; the OpenID Foundation is the change controller.¶

8.2. Media Type Registration

This document requests registration of the following media type in the "Media Types" registry, for use as the value of the typ JOSE header parameter and, where applicable, the Content-Type of an OpenID Authentication Token.¶

Type name:

application¶

Subtype name:

authn+jwt¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary; a JWT is a series of base64url-encoded values with period separators.¶

Security considerations:

See Section 11 of [RFC7519] and the Security Considerations of this document.¶

Change controller:

OpenID Foundation¶

8.3. OAuth Extensions Error Registration

This document requests registration of the following error code in the "OAuth Extensions Error Registry" established by [RFC6749].¶

Name:

invalid_key_binding¶

Usage Location:

token error response¶

Protocol Extension:

OpenID Authentication Token Protocol (this document)¶

Change controller:

OpenID Foundation¶

Reference:

Section 4.5 of this document¶

8.4. OpenID Provider Metadata Registration

This document requests registration of the metadata parameters authn_token_endpoint and authn_token_signing_alg_values_supported in the "OpenID Connect Discovery 1.0" / "OAuth Authorization Server Metadata" registries, with this document as the specification document and the OpenID Foundation as the change controller.¶

9.1. Normative References

[OpenID.Core]

Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 2", 15 December 2023, <https://openid.net/specs/openid-connect-core-1_0.html>.

[OpenID.KeyBinding]

OpenID Connect Working Group, "OpenID Connect Key Binding", n.d., <https://openid.github.io/connect-key-binding/main.html>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7517]

Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/rfc/rfc7517>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/rfc/rfc7638>.

[RFC7800]

Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, <https://www.rfc-editor.org/rfc/rfc7800>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

9.2. Informative References

[OpenID.Discovery]

Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 2", 15 December 2023, <https://openid.net/specs/openid-connect-discovery-1_0.html>.

[RFC6750]

Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/rfc/rfc6750>.

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/rfc/rfc8414>.