A sender-constrained access token is usable only by a specific sender, which must prove knowledge of a secret before a resource server accepts it. The authorization server binds the token to the client, usually with key material known to the client; the resource server performs the proof-of-possession check and prevents replay of the proof. OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (RFC 8705) identifies the client by the fingerprint of its public key: the authorization server obtains the client public key from the TLS stack and associates its fingerprint with the token, and the resource server compares fingerprints the same way. OAuth 2.0 Demonstrating Proof of Possession (DPoP, RFC 9449) is an application-level mechanism using a public/private key pair and application-level signing; it works with public clients and, for confidential clients, combines with any client authentication method. Security is undermined if an attacker obtains both token and key material, for example via cross-site scripting in a browser client; key material held in a security module or TLS stack at least protects the token while the client is offline. Scope: OAuth 2.0 security. Reviewed October 4, 2026.
Sender-constrained tokens with mTLS and DPoP
Document v1 · published by Koskamo editorial · updated 2026-10-04
Source and provenance
- Original source
- datatracker.ietf.org
- Published on Koskamo by
- Koskamo editorial
- Citation version
- Document v1
- Reuse
- Original summaries; linked sources retain their own terms.