]> Independent

public@karlmcguinness.com

Security Web Authorization Protocol oauth token exchange confirmation dpop mtls proof of possession This specification defines a cnf response parameter for the OAuth 2.0 Token Exchange (RFC 8693) response. The parameter carries the confirmation method that the authorization server applied to the issued token, enabling clients to verify that sender-constraint binding (for example a DPoP key or mutual-TLS client certificate) was performed without inspecting the issued token. This is useful for opaque tokens, encrypted tokens, or any other case where the client cannot read the issued token's cnf claim directly. About This Document Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at .

Introduction OAuth 2.0 Token Exchange defines a protocol for exchanging one security token for another. The Token Exchange request can convey inputs that trigger the authorization server to issue a sender-constrained token: a DPoP proof in the request header, a mutual-TLS client certificate , or a future sender-constraint method. When the authorization server applies sender-constraining to the issued token, the primary signal to the client is the cnf claim () inside the issued token. For JWT-formatted tokens the client can read, this works. The signal fails in three deployment shapes:

1. Opaque tokens. The issued token is an unstructured string and the client cannot read any claim from it.
2. Encrypted tokens. The issued token is a JWE encrypted to a downstream consumer (such as a Resource Authorization Server ), and the client does not hold the decryption key.
3. token_type is "N_A". requires the token_type response parameter to be N_A when the issued token is not used directly as an access token. Existing sender-constraint methods, such as DPoP , rely on token_type carrying the binding method (token_type: "DPoP"), and that signal is unavailable here.

Without a protocol-level signal in the Token Exchange response, an authorization server that silently fails to apply sender-constraining (by error or by misbehavior) can downgrade the issued token without the client noticing. This document closes the gap by adding an optional cnf parameter to the Token Exchange response. The parameter carries the same confirmation structure that defines for the cnf claim. The client verifies the response cnf against the key or certificate it provided in the request, the same way it would verify the in-token cnf claim, and treats absence (when sender-constraining was expected) as a downgrade.

Conventions and Definitions 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 () () when, and only when, they appear in all capitals, as shown here. This document uses the terms "access token," "authorization server," "client," "resource server," and "token endpoint" defined by OAuth 2.0 . The "issued token" is the token returned in the access_token member of a Token Exchange response (). A "confirmation method" is a sender-constraint binding mechanism registered in the "JWT Confirmation Methods" registry established by , such as the JWK SHA-256 Thumbprint (jkt) defined in and the X.509 Certificate SHA-256 Thumbprint (x5t#S256) defined in .

Confirmation Response Parameter This specification adds the following optional parameter to the Token Exchange response defined in :

cnf:

OPTIONAL. A JSON object containing one or more confirmation members as defined in . The value identifies the confirmation method that the authorization server applied to the issued token, allowing the client to verify the sender-constraint binding without inspecting the issued token.

The parameter's structure and member names are those of the cnf JWT claim ; this document defines no new confirmation methods. Conveying a token's confirmation outside the token follows the precedent of token introspection (; ). The parameter describes only the issued token, not any refresh_token returned in the same response. It is defined only for Token Exchange responses; its use with other grant types is out of scope. Clients that do not support this specification ignore unrecognized response members ().

Relationship to the In-Token cnf Claim When the issued token is a JWT carrying a cnf claim, the cnf response parameter MUST represent the same confirmation as that claim: the same confirmation member name(s) identifying the same key or certificate. The parameter does not replace the claim; the client verifies the binding from the response while the token's consumer validates it from the token itself. A client that can read the issued token's cnf claim MUST reject the response if the two values do not represent the same confirmation. Wherever this document compares two cnf values (a response parameter against an in-token claim, or against the client's sender-constraint input), the comparison is by confirmation method and value, not by byte representation:

• JSON member ordering and insignificant whitespace are ignored.
• A thumbprint member (for example jkt or x5t#S256) is compared as the base64url-encoded string it represents.
• A full public key in a jwk member is compared against a thumbprint by computing the key's JWK SHA-256 Thumbprint ().

These rules avoid a dependency on any particular JSON canonicalization scheme.

Authorization Server Behavior When the authorization server applies sender-constraining to the token it issues in response to a Token Exchange request:

• It MUST include the cnf parameter in the Token Exchange response.
• The confirmation member name and value MUST identify the confirmation method actually applied to the issued token.
• The cnf parameter SHOULD contain exactly one confirmation member and MUST NOT contain a member identifying a binding that was not applied.

When the authorization server does not apply sender-constraining to the issued token, it MUST NOT include the cnf parameter in the response. When the authorization server receives sender-constraint input (for example a DPoP proof header or a mutual-TLS client certificate) but does not apply the binding, it SHOULD reject the request with an error response () rather than issue an unbound token. If it issues the token anyway, omitting cnf signals the downgrade to the client.

Client Behavior A client that provides sender-constraint input in a Token Exchange request (for example a DPoP proof or a mutual-TLS client certificate) MUST validate the Token Exchange response as follows:

1. The client MUST treat a cnf value that is not a JSON object, or is an empty JSON object, as if cnf were absent.
2. If the response does not contain a cnf parameter (or contains one treated as absent per the previous rule), the client MUST treat the issued token as not sender-constrained. A client that requires sender-constraining MUST reject the response and not use the issued token.
3. Otherwise, the client MUST verify that cnf contains the confirmation member corresponding to its sender-constraint input and that the member's value matches that input:
   • For a DPoP proof: a jkt member whose value equals the JWK SHA-256 Thumbprint () of the public key in the DPoP proof JWT.
   • For a mutual-TLS client certificate: an x5t#S256 member whose value equals the base64url-encoded SHA-256 hash of the certificate's DER encoding ().
   If the corresponding member is absent or its value does not match, the client MUST reject the response and not use the issued token. The client MUST ignore any other confirmation members.

Absence of cnf indicates either a downgrade (intentional or otherwise) or an authorization server that does not implement this specification; the rules above treat both the same. A client that did not provide sender-constraint input but receives a response containing cnf holds a token bound to the identified key or certificate. If the client holds that key or certificate (for example, the certificate it used for mutual-TLS client authentication), it MAY use the issued token and SHOULD satisfy the confirmation method when presenting it. Otherwise the issued token is unusable, and the client SHOULD treat the response as an error.

Examples The examples in this section illustrate the cnf response parameter for different confirmation methods. Extra line breaks in request bodies and header fields are for display purposes only.

DPoP-Bound Token A client includes a DPoP proof header in a Token Exchange request for an Identity Assertion JWT Authorization Grant (ID-JAG) . Because token_type is N_A for an ID-JAG, it cannot signal the binding; the authorization server instead includes cnf with a jkt member in the response. The client compares the jkt value to the JWK SHA-256 Thumbprint of its DPoP public key and rejects the response on mismatch.

Mutual-TLS-Bound Token A client establishes a mutual-TLS connection to the token endpoint and presents a client certificate. The authorization server applies the binding and includes cnf with an x5t#S256 member in the response.

No Sender-Constraint Applied The client did not supply a DPoP proof or a mutual-TLS client certificate. The authorization server issues an unbound token and omits cnf. A client that provided sender-constraint input treats this token as unbound and, if it requires sender-constraining, rejects the response ().

Security Considerations

The Response Parameter Is Informational The cnf response parameter is informational. Authoritative enforcement of the binding occurs when the issued token is presented to its consumer (a resource server or another authorization server), which validates the token's cnf claim against the presenter's proof. A verified response cnf tells the client only that the authorization server did not downgrade issuance, not that the token's consumer will enforce the binding; both checks are needed end-to-end. This check defends against an authorization server that fails to apply sender-constraining through error or misconfiguration. It does not defend against a malicious authorization server, which issues the token and controls its contents entirely. Protection against a hostile issuer is out of scope for this document.

TLS for the Response TLS, already required for the token endpoint by , prevents an on-path attacker from stripping or modifying the cnf parameter to suppress the binding signal.

Replay and Freshness This specification does not itself prevent replay of the response cnf value. The replay protections of the underlying sender-constraint method continue to apply: the DPoP nonce and jti () and, for mutual TLS, the live TLS session.

Disclosure The cnf response parameter discloses the binding method and a key or certificate thumbprint only to the client that initiated the request, which already holds the corresponding key material. A thumbprint is a one-way hash and reveals no additional personal data, though it is a stable correlator for the bound key. Authorization servers SHOULD use a thumbprint member (such as jkt) rather than a full jwk member: the client can recompute the thumbprint from the key it already holds, so a full key discloses more material than verification requires and enlarges the response.

IANA Considerations IANA is requested to register the following parameter in the "OAuth Parameters" registry established by :

• Parameter Name: cnf
• Parameter Usage Location: token response
• Change Controller: IETF
• Specification Document(s): of this document

References Normative References The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. 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. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Okta Independent Ping Identity This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through an identity provider that the downstream Resource Authorization Server already trusts for single sign-on (SSO), using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. This pattern is informally referred to as Cross-App Access (XAA).

Acknowledgments The gap addressed by this specification was identified during work on "OAuth Identity Assertion Authorization Grant" , where the combination of token_type: "N_A" (mandated by ) and optional ID-JAG encryption removed the existing client-side path for detecting sender-constraint downgrade.

Document History -00

• Initial draft.