Skip to main content
Identity Authority
Category: Tokens & Sessions

Token Binding

Also known as: TLS Token Binding
Simply put

Token Binding is a security technique that cryptographically ties a token, such as a session or authentication token, to the specific secure connection over which it was issued. This means that if an attacker steals the token, they typically cannot use it from a different device or connection because they lack the associated cryptographic key. The goal is to reduce the risk of token theft and replay.

Formal definition

Token Binding is a proposed TLS extension that allows a client and server to establish a long-lived cryptographic key pair, proof of possession of which is demonstrated over the TLS connection, and then bind issued tokens to that key pair. In practice, this cryptographically associates tokens (for example OAuth 2.0 refresh tokens per draft-ietf-oauth-token-binding, or OpenID Connect ID Tokens per the OpenID Connect Token Bound Authentication draft) with the TLS connection(s) on which they were established, so that a token exfiltrated from a client cannot be replayed by a party that does not hold the corresponding Token Binding private key. Note that binding is a possession-of-key mechanism layered on TLS and is distinct from token encryption; the binding constrains where a token can be validly presented rather than concealing its contents. Deployment behavior, key scope, and enforcement vary by specification profile and vendor implementation, and some vendor mechanisms marketed as token binding or token protection (for example Microsoft Entra Token Protection) may differ from the IETF TLS Token Binding standard in their underlying approach.

Why it matters

Bearer tokens are a foundational mechanism in modern identity systems, but their central weakness is that possession equals authority: any party holding a valid session token, OAuth 2.0 refresh token, or OpenID Connect ID Token can typically present it and be granted access, regardless of how the token was obtained. This makes token theft, through malware, cross-site scripting, phishing proxies, or compromised endpoints, a high-value attack path. Token Binding addresses this class of risk by cryptographically tying a token to the specific TLS connection over which it was issued, so that a token exfiltrated from a client cannot be replayed by an attacker who does not hold the corresponding Token Binding private key.

The practical value is that binding shifts the security property from possession of a token to possession of a non-exportable cryptographic key. As the FIDO Alliance has described, Token Binding ties a token to a host so the server can gain assurance that it is communicating with the legitimate client rather than an impersonator replaying a stolen credential. It is important to be precise about what this does and does not do: binding constrains where a token can be validly presented, but it is distinct from token encryption and does not conceal a token's contents. It also does not replace the underlying issuance, authorization, or revocation controls around the token.

Adoption context matters when relying on token binding. The IETF TLS Token Binding work is a proposed standard, and its OAuth and OpenID Connect profiles are defined in drafts rather than finalized, widely deployed specifications. Separately, some vendor mechanisms marketed as token binding or token protection, for example Microsoft Entra Token Protection, pursue the same anti-replay goal but may differ from the IETF TLS Token Binding standard in their underlying approach. Teams evaluating token binding should therefore verify what a given product actually implements rather than assuming interoperability with the TLS extension.

Who it's relevant to

Security Architects
Architects evaluating defenses against token theft and replay should understand token binding as a proof-of-possession control layered on TLS, and weigh it against alternatives given that the IETF TLS Token Binding standard and its OAuth/OpenID Connect profiles remain at draft or proposed-standard status. They should also distinguish standards-based binding from vendor mechanisms such as Microsoft Entra Token Protection, which may take a different underlying approach to the same anti-replay goal.
IAM and Identity Engineers
Engineers implementing OAuth 2.0 and OpenID Connect flows need to know which tokens can be bound, for example refresh tokens per draft-ietf-oauth-token-binding or ID Tokens per the OpenID Connect Token Bound Authentication draft, and how binding depends on client and server support for the underlying TLS extension. Because deployment behavior and key scope vary by profile and implementation, engineers should confirm actual capabilities rather than assume portability across products.
Compliance and Governance Leads
Governance and compliance stakeholders concerned with credential protection should recognize that token binding reduces replay risk by constraining where a token can be validly presented, but does not encrypt token contents and does not replace lifecycle controls such as issuance, authorization, and revocation. When assessing a vendor claim of token binding or token protection, they should verify whether it aligns with the IETF standard or a vendor-specific mechanism.

Inside Token Binding

Token Binding Protocol
A mechanism, historically specified in a set of IETF RFCs, that cryptographically associates security tokens (such as cookies, OAuth 2.0 tokens, or OpenID Connect tokens) with a TLS connection, so a token presented over a different connection cannot be used by an attacker.
Token Binding ID
An identifier derived from a client-generated public/private key pair. The client proves possession of the private key during the TLS handshake, and the resulting Token Binding ID is used to bind issued tokens to that key.
Proof of Possession
The core property Token Binding provides: it turns otherwise bearer tokens into proof-of-possession tokens, requiring the presenter to demonstrate control of the associated private key rather than merely holding the token.
TLS Layer Integration
Token Binding typically operates as a TLS extension, negotiating binding parameters during the handshake, which means both client and server must support the capability for it to take effect.
Bound Token Types
The tokens that can be bound depend on the deployment and may include session cookies, OAuth 2.0 access and refresh tokens, and OpenID Connect ID tokens, subject to server and client support.

Common questions

Answers to the questions practitioners most commonly ask about Token Binding.

Does Token Binding encrypt the token so it can't be read if intercepted?
No. Token Binding does not encrypt the token or its contents. It cryptographically associates a token with a client-held private key so that a stolen or exfiltrated token cannot be replayed from a different client that lacks the corresponding key. Confidentiality of the token in transit is typically provided by the underlying TLS channel, not by Token Binding itself. If you need the token payload to be unreadable at rest or by intermediaries, that is a separate concern addressed by encryption mechanisms rather than by binding.
Is Token Binding just another form of authentication that replaces MFA or credential verification?
No. Token Binding is not an authentication method and does not verify who the principal is. It operates after authentication has occurred, binding an already-issued token to a specific client key so the token cannot be used elsewhere. It complements authentication and authorization mechanisms rather than replacing them; MFA and credential verification still establish the principal's identity, while Token Binding addresses token replay and theft during the token's usable lifetime.
What client and server components typically need to support Token Binding for it to work end to end?
In most deployments, Token Binding requires support at both the TLS layer and the application layer. The client (often a browser or user agent) must be able to generate and hold the binding key and present the associated Token Binding messages during the TLS handshake, and the server-side endpoint must be able to negotiate the capability and validate the binding. Because it depends on negotiation between both parties, support gaps at either end, or at intermediating proxies and load balancers that terminate TLS, can prevent binding from being established. Verify TLS termination behavior in your architecture before relying on it.
How does TLS termination at a proxy or load balancer affect Token Binding?
Depending on configuration, TLS-terminating intermediaries can break Token Binding because the binding is tied to the TLS connection between the client and the terminating endpoint. If a proxy or load balancer terminates TLS before the application server, the binding key seen at the edge may differ from what the application expects, or the binding context may not be propagated downstream. In such architectures you typically need the terminating component itself to participate in binding validation and to forward the relevant binding information, or you must design around the limitation. Assess each hop where TLS is terminated.
Which token types can Token Binding be applied to?
Token Binding can, depending on the profile and deployment, be applied to different token types used in a session, including bearer-style artifacts that would otherwise be replayable if stolen. The intent is to convert a bearer token into one that is only usable by the client holding the bound key. Whether a given access token, refresh token, or session cookie can be bound depends on the supporting standards, the issuing and validating parties implementing the corresponding checks, and the surrounding protocol profile. Confirm which specific token types your issuer and relying components support binding for rather than assuming uniform coverage.
What should be considered when adoption or client support for Token Binding is inconsistent?
Because support has historically been uneven across clients, servers, and intermediaries, deployments typically need a fallback strategy for parties that cannot negotiate binding. This often means defining whether unbound tokens are still accepted, and under what risk conditions, versus enforcing binding strictly. Note that permitting fallback to unbound tokens can weaken the replay protection the mechanism is intended to provide, so the decision is a trade-off between compatibility and security posture. Evaluate current support in your client population and layer additional controls where binding cannot be guaranteed.

Common misconceptions

Token Binding encrypts the token so its contents are protected.
Token Binding does not encrypt token contents. It cryptographically associates a token with a TLS connection key to prevent token export and replay; confidentiality of token contents, where needed, is a separate concern typically handled by the transport layer or token encryption.
Token Binding authenticates the user.
Token Binding does not perform user authentication. It binds an already-issued token to a client key to resist token theft and replay; identifying and authenticating the principal remain separate steps handled by the underlying authentication protocol or layer.
Enabling Token Binding is a client-only or server-only change.
Because Token Binding is negotiated during the TLS handshake, it typically requires support on both endpoints and, in many deployments, across intermediaries. Adoption has been limited by uneven browser and infrastructure support, so its practical availability depends heavily on the environment.

Best practices

Verify that both client and server endpoints, along with any TLS-terminating intermediaries such as load balancers and proxies, support Token Binding before relying on it, since it only takes effect when negotiated end to end.
Treat Token Binding as a mitigation against token theft and replay rather than a substitute for authentication or token encryption, and layer it alongside those separate controls.
Apply Token Binding to high-value tokens such as session cookies and OAuth 2.0 refresh and access tokens where proof of possession meaningfully reduces replay risk.
Confirm that servers validate the Token Binding ID on every request, so tokens presented over a connection lacking the correct bound key are rejected.
Assess current browser, client library, and infrastructure support before committing to Token Binding, and plan graceful fallback behavior for endpoints that do not negotiate it.
Document Token Binding as a configuration-dependent control whose availability and enforcement vary by deployment, and monitor for cases where negotiation silently fails.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide