After a user signs in, most systems issue a token, a session cookie or an access token, that the client presents on later requests so that it need not authenticate again. This makes the token as valuable as the credentials that produced it. Most tokens are bearer tokens, meaning that whoever possesses one is treated as the legitimate user. If an attacker steals the token through malware, a compromised proxy, a log file or a cross-site scripting flaw, they can replay it from their own machine, and multi-factor authentication does nothing to prevent it because the authentication has already happened. The attack has become common enough that defenders now focus on token theft as much as on password theft, and token binding is one of the main defences.
How does token binding work?
The idea is to tie a token to something that only the legitimate client possesses, so that the token on its own is not enough. The client holds a private cryptographic key, and the token is issued with a reference to the matching public key. When the client uses the token, it also proves possession of the private key, for example by signing part of the request or by using the key in the connection itself. The server checks both. A thief who copies the token has no key and therefore cannot produce the proof, and the stolen token fails. The private key should be kept somewhere that is hard to export, such as secure hardware, which raises the cost of theft considerably.
What happened to the original protocol?
The Token Binding standards, published by the IETF as RFC 8471 and related documents, tied tokens to the TLS connection by using a key negotiated between browser and server. Browser support was implemented in some browsers and later withdrawn, in part because of complexity and the difficulty of deploying it through proxies and content delivery networks that terminate TLS. The underlying goal remains important, and newer mechanisms pursue it by different routes. OAuth 2.0 mutual TLS, described in RFC 8705, binds access tokens to a client certificate. Demonstrating Proof of Possession, or DPoP, in RFC 9449, has the client sign each request with a key tied to the token, and it works at the application layer, which makes it easier to deploy.
Benefits and implementation challenges
Bound tokens reduce the value of stolen tokens, limit the damage from leaked logs and make replay attacks harder, without changing the experience for the user. They are particularly useful for high-value sessions and for machine-to-machine access, where keys can be managed in hardware or by a platform. The challenges are practical. Keys must be generated, stored and rotated across devices, and clients that lose their key must re-authenticate. Intermediaries that terminate connections can break bindings tied to TLS. Every service that accepts the tokens must implement the checks correctly, and mixed deployments need a safe fallback. Short token lifetimes, which are good practice regardless, complement binding by limiting how long a stolen token is useful.
Why it matters
As strong authentication spreads, attackers shift to the weakest remaining link, and the session token is an obvious one. Binding tokens to the client that earned them closes that gap and makes authentication result in something that cannot be passed on. Organisations designing sign-in and API access can adopt it incrementally, starting with their most sensitive services.
A token that anyone can use is a password with a shorter life. Binding makes it belong to one client.
