Sender-Constrained Tokens: DPoP and mTLS

Two new client authentication methods sit alongside client_secret_basic / client_secret_post / private_key_jwt (covered on Client Credentials and Client Authentication):

Whichever authentication method was used — including plain client_secret_basic, as long as the client also presented a certificate on the same TLS connection — the authorization server may bind the issued access token to that certificate, independent of how the client authenticated. It does this by embedding the certificate’s SHA-256 thumbprint in the token, under the cnf claim defined by RFC 7800, using the confirmation-method member x5t#S256:

The resource server, presented with this token, must independently verify that the TLS client certificate presented on its own connection produces the same SHA-256 thumbprint recorded in x5t#S256. If the token is replayed over a connection authenticated with a different certificate — or with no client certificate at all — the resource server rejects it, regardless of how cryptographically valid the token itself is. Introspection responses (RFC 7662) carry the same cnf structure, so a resource server that validates by introspection rather than locally can perform the same check.

Mutual TLS suits deployments that already run a PKI — an internal service mesh, a partner integration where certificates are already provisioned and rotated, a regulated environment (FAPI, covered on PAR, JAR and Hardened Profiles, mandates it) — because the certificate infrastructure is not new work. It is a poor fit where no PKI exists yet, where clients are short-lived or highly dynamic (mobile apps, browser sessions), or where certificate provisioning and rotation cannot be automated.

On every request to the token endpoint or a protected resource, the client attaches a DPoP header carrying a freshly-signed JWT — the DPoP proof. Its JOSE header identifies it as a DPoP proof and carries the public key, not a key identifier:

and its claims bind the proof to exactly one request, at exactly one moment, made by exactly one client:

The whole thing is signed by the private key matching the jwk in the header, so the resource server can verify the signature using the public key embedded right there in the proof — no separate key-distribution step is needed.

When the authorization server issues an access token in response to a request that included a DPoP proof, it computes the JWK SHA-256 thumbprint (RFC 7638) of the client’s public key and embeds it in the token under cnf, using the confirmation-method member jkt:

A resource server receiving a request must: verify the DPoP proof’s signature against the jwk in its header; recompute that key’s thumbprint and confirm it equals the token’s cnf.jkt; verify htm/htu match the incoming request; verify ath matches the SHA-256 hash of the access token actually presented; and verify iat/jti fall inside an acceptable, short freshness window it has not already seen. Only when every one of those checks passes does the token count as valid for this request, on top of whatever ordinary validity checks (signature, exp, aud, scope) apply regardless of DPoP.

Note the scheme changes from Bearer to DPoP in the Authorization header — this is itself a signal to the resource server that proof-of-possession checking applies to this request.

A DPoP proof’s iat and jti alone bound a replay window, not eliminate replay entirely: within that short window, a captured proof could in principle be reused. RFC 9449 lets a server (authorization server or resource server) raise the bar by issuing a DPoP-Nonce value in a response header, which the client must then echo back inside the next proof’s claims. A request whose proof lacks the currently expected nonce is rejected with a use_dpop_nonce error and a fresh nonce, forcing the client to mint a new, nonce-bound proof for every subsequent call — collapsing the effective replay window from "a short time interval" to "exactly one request." Servers that support nonces should treat each nonce as single-use and rotate it on every response, so neither a captured proof nor a captured nonce is independently reusable. Resource servers still normally cap the acceptable iat age (a small number of seconds) as a defence-in-depth measure even where nonces are in use.

Where the DPoP private key is generated and stored matters as much as the proof format itself:

DPoP is not limited to access tokens: a refresh token can carry the same cnf/jkt binding, and RFC 9449 requires it for public clients using refresh tokens with DPoP — every refresh_token grant request must itself be accompanied by a DPoP proof signed with the same key the original token issuance was bound to, and the authorization server rejects the exchange if the proof’s key does not match. This closes exactly the refresh-token-theft scenario Security Best Practices and Access and Refresh Tokens describe rotation and reuse detection for: a stolen refresh token, sender-constrained this way, cannot be redeemed by the thief at all, rotation and reuse detection notwithstanding, because the thief does not hold the private key the token is bound to.

A resource server that validates tokens locally (a JWT access token, at+jwt per RFC 9068) checks cnf directly against the incoming request as described above. A resource server that instead validates by calling the authorization server’s introspection endpoint (RFC 7662, covered on Opaque Tokens, Introspection and Revocation) receives the same cnf structure inside the introspection response body, and must perform the identical DPoP-proof or mTLS-certificate comparison itself — introspection confirms the token is active, but whether this caller is the one the token was bound to is always the resource server’s own responsibility, on every request, never something the authorization server can verify on the resource server’s behalf after the fact.