Token binding is a protocol that cryptographically ties a security token to the TLS layer so a stolen token cannot be replayed from another machine. RFC 9449 notes it lacks browser support. APIs wanting the same protection today use DPoP or mutual TLS certificate bound tokens.
The problem token binding tried to solve
Most APIs use bearer tokens. RFC 6750 defines the bearer model: anyone who holds the token can use it, with no proof of anything else. That is convenient and also the weakness. If a token leaks from a log, a proxy, a crash report or an infected device, the thief can replay it until it expires.
Sender constraining changes the rule. The token is bound to a key held by the legitimate client, and the server checks that the caller can prove possession of that key. A copied token alone is no longer enough.
What token binding was
RFC 8471, published in October 2018, specifies version 1.0 of the Token Binding protocol. Its abstract says it lets client and server applications create long lived, uniquely identifiable TLS bindings that span multiple TLS sessions and connections, so applications can cryptographically bind security tokens to the TLS layer and prevent token export and replay attacks.
The idea was sound: use a key the client holds, and carry the proof in the same TLS channel the token travels over. The difficulty was deployment. It needed support in browsers, in TLS libraries and in servers, and in front of many APIs there are load balancers and gateways that terminate TLS.
Why newer standards took over
The DPoP specification, RFC 9449, is explicit about why it exists. It says the application level approach can be used where methods based on the transport layer, naming RFC 8705 and token binding, are not available or desirable. It notes that, because of a sub-par user experience of TLS client authentication in browsers and a lack of support for HTTP token binding, neither can be used for a single page application running in a browser.
DPoP moves the proof to the application layer. The client sends an HTTP header containing a signed JWT that shows it holds the private key, and the server checks the binding.
RFC 8705 takes a different route for clients that can use mutual TLS: the access token is bound to the client certificate.
The options compared
| Approach | Where the proof lives | Fits well | Watch out for |
|---|---|---|---|
| Bearer token | Nowhere | Low risk, short lived tokens | Replay after theft |
| Token binding | TLS layer | Where both ends support it | Lack of support in browsers, as RFC 9449 notes |
| Certificate bound tokens (mTLS) | TLS client certificate | Server to server and partner APIs | TLS termination at proxies, certificate management |
| DPoP | Signed header on each request | Mobile apps, single page apps, public clients | Replay of proofs, key storage |
How to choose
- If tokens are short lived, narrowly scoped and your risk is low, bearer tokens with good hygiene may be enough.
- If clients are server side partners who can manage certificates, consider mutual TLS bound tokens.
- If clients are mobile or browser apps, look at DPoP, and store the private key so it cannot be exported where the platform allows.
- Whatever you choose, keep access tokens short lived and scoped. Sender constraining reduces replay risk, it does not replace least privilege.
What to ask your identity provider
Ask whether it can issue DPoP bound or certificate bound tokens, whether your gateway can verify them, and how it handles proof replay. Many gateways verify JWT signatures and scopes but do not yet check the binding, so test that the check really happens.
Safeguard's asset discovery helps you find API hosts and versions you may have lost track of, and its SBOM and dependency scanning shows which libraries ship in your builds. You can start with the free scan at gold.safeguard.sh/scan.
Quick check
Is token binding the same as DPoP?
No. Token binding works at the TLS layer. DPoP works at the HTTP application layer using a signed header, and RFC 9449 says it fits cases where transport layer methods are not available.
Do short lived bearer tokens make binding unnecessary?
They reduce the window for replay but do not remove it. Binding matters most when tokens are long lived or very sensitive.
Sources
- RFC 8471, The Token Binding Protocol Version 1.0
- RFC 9449, OAuth 2.0 Demonstrating Proof of Possession (DPoP)
- RFC 8705, OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
- RFC 6750, The OAuth 2.0 Authorization Framework: Bearer Token Usage
Last reviewed: 19 October 2026.
