Identity term · last reviewed 2026-08-14
Token Binding
Token Binding (RFC 8471) was a TLS-layer standard that cryptographically bound a token to its connection so it couldn't be replayed elsewhere; both major browsers dropped support by 2020, and DPoP now delivers the same sender-constrained-token goal at the application layer.
How it works
Token Binding (RFC 8471) cryptographically ties a token to the TLS connection it was issued on. The client generates a key pair per connection, proves possession via a TLS extension during the handshake, and the server stamps that key's identifier into the token. A stolen token is useless off that specific TLS channel, which kills the entire "steal a bearer token, replay it from anywhere" attack class. Chrome and Firefox shipped early support, then both dropped it between 2018 and 2020: the TLS-layer plumbing was fragile across proxies and load balancers, and browser vendors decided it wasn't worth maintaining. Treat it as dead, not as a standard you can build on.
The goal it was chasing, sender-constrained tokens instead of bearer tokens, didn't die with it. DPoP (RFC 9449) achieves the same thing at the application layer: the client signs a proof-of-possession JWT with its own key and attaches it to each request, no TLS extension or browser support required. mTLS client certificates (RFC 8705) solve the same problem for OAuth clients that can manage certificates.
When it matters
You need sender-constraining when bearer tokens alone aren't enough, high-value APIs (banking, healthcare, anything handling money or PHI) where a leaked access token being replayed from an attacker's machine is unacceptable. For that, reach for DPoP, not Token Binding. For most B2B SaaS APIs, short-lived access tokens plus refresh token rotation is sufficient and DPoP is premature complexity.
Common misconceptions
- "Token Binding is a current best practice for OAuth." It's dead. No browser has supported it since 2020; don't spec it into a new design.
- "DPoP needs the same browser-level support Token Binding did." It doesn't. DPoP is just a signed JWT header your client library generates, it works in any HTTP stack today.
- "Sender-constrained tokens are too complex to bother with." DPoP support is already built into major OAuth libraries (e.g., Okta's SDKs, Duende IdentityServer); it's a config flag, not a research project.
Related terms
Explained in depth