Sender-constrained tokens and what Token Binding failed to teach

At a glance

What this is: This is an analysis of sender-constrained OAuth tokens, showing how mTLS and DPoP bind tokens to the legitimate client while Token Binding failed on deployability.

Why it matters: It matters because IAM, PAM, and NHI teams need controls that survive token theft without breaking real-world delivery paths, gateways, and browser-based clients.

By the numbers:

• Google removed Token Binding support entirely in Chrome 130 in 2024.
• DPoP has seen rapid adoption since its standardisation in 2023.

👉 Read WorkOS's analysis of sender-constrained tokens and token binding

Context

Bearer access tokens are a trust problem as much as an authentication problem. If a token is intercepted, replayed, or copied out of logs, the resource server sees valid credentials unless the token is bound to the client that legitimately holds it. That is the core sender-constraining problem for OAuth in modern IAM and NHI environments.

The practical question for security architects is not whether proof-of-possession is desirable, but which binding model can survive real deployment constraints. mTLS and DPoP solve the same control gap through different layers, while Token Binding shows what happens when a good cryptographic idea depends on too many infrastructure changes at once.

For teams governing machine-to-machine access, browser clients, and service identities, this is a useful split: the control must fit the actor type and the delivery path. That is why sender-constrained tokens belong in access design discussions, not only protocol discussions.

Key questions

Q: How should security teams prevent OAuth token replay in modern architectures?

A: The most reliable approach is to bind the token to the client that legitimately holds it. Use mTLS for controlled machine-to-machine flows and DPoP for browser, mobile, or intermediary-heavy paths. Bearer-only tokens should be treated as a residual risk where replay would materially widen access to APIs or downstream data.

Q: When should organisations choose mTLS over DPoP for access tokens?

A: Choose mTLS when you control both ends of the connection, can enforce end-to-end TLS, and already manage certificates at scale. Choose DPoP when TLS terminates at gateways, when browser clients are involved, or when the architecture needs application-layer proof that survives intermediaries.

Q: What do teams get wrong about sender-constrained tokens?

A: They often treat sender-constraining as a cryptography problem only. In practice, the adoption barrier is architectural. The chosen mechanism has to fit browser support, proxy behaviour, certificate operations, and the request path, or it will fail to deploy even if the protocol is sound.

Q: Who is accountable for proof-of-possession controls in OAuth environments?

A: Accountability usually sits with the identity, platform, and application teams together. Identity owns the token binding policy, platform teams own TLS termination and gateway behaviour, and application teams own request validation and client path design. If any one of those layers breaks the proof chain, the control fails.

Technical breakdown

Bearer tokens versus proof-of-possession tokens

Bearer tokens work on possession alone, which means any party that captures the token can present it. Proof-of-possession changes the trust model by requiring the client to prove it still holds the associated key material at request time. In OAuth, that proof can be carried at the TLS layer, as with mTLS, or at the HTTP layer, as with DPoP. The security property is the same, but the operational placement is different. That distinction matters because token replay, proxy leakage, and log exposure remain common failure paths even when the token lifetime is short.

Practical implication: choose a sender-constraining mechanism wherever token replay would materially widen blast radius.

How mTLS binds OAuth tokens to a client certificate

mTLS uses the transport layer to prove identity. The authorization server embeds a certificate thumbprint in the token, and the resource server compares that thumbprint with the client certificate presented during the TLS handshake. This keeps the binding outside application code, which simplifies verification in back-end service flows. The trade-off is operational: TLS must terminate where the certificate can be checked, and certificate lifecycle management becomes part of access governance. That makes mTLS a good fit for controlled service-to-service paths, but less practical when intermediaries terminate TLS or when browser clients are involved.

Practical implication: use mTLS where certificate issuance, termination, and rotation are already governed end to end.

Why DPoP survives intermediaries and browser clients

DPoP moves proof-of-possession into the application layer by sending a signed proof JWT on each request. The proof includes the HTTP method, URI, a timestamp, and a nonce, so the resource server can verify that the token is being used for the intended request and not replayed elsewhere. Because it rides in HTTP headers, DPoP works even when TLS is terminated at a gateway or load balancer. It is also browser-friendly because JavaScript can hold the key pair and generate the proof. The added complexity is per-request signing and nonce handling, not transport dependency.

Practical implication: use DPoP when application-level proxies, browser clients, or mobile apps make transport-layer binding unworkable.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Sender-constrained tokens are now an access governance requirement, not an optional hardening layer. Bearer tokens are still the default trust model in many environments, but that model collapses the moment tokens can be copied, intercepted, or replayed outside the intended client context. The governance issue is not token strength alone, but whether the identity system can prove the presenter is the legitimate holder. For IAM and NHI programmes, that shifts sender-constraining from a protocol choice to a control boundary decision.

Token Binding failed because it assumed the whole ecosystem would modernise at once. That assumption was designed for a world where browsers, TLS libraries, proxies, and applications could all upgrade in lockstep. That assumption fails when the actor is an enterprise platform made up of independent termination points and vendor-managed intermediaries. The implication is not to demand stronger theory, but to recognise that deployability is part of security design.

mTLS and DPoP show that proof-of-possession only matters when it matches the actor path. Backend services can usually tolerate certificate-based binding and centralised issuance, while browser and mobile clients need HTTP-layer proof that survives TLS termination. This is a classic identity architecture lesson: the same access control objective requires different execution models for machine identities and user-facing clients. Practitioners should treat client path as a first-class control requirement.

Incremental adoption beats theoretical completeness when token replay is the threat. Token Binding was cleaner on paper because it lived in the transport stack, but that elegance did not survive browser and infrastructure reality. DPoP and mTLS are less uniform, yet they can be introduced without rewriting the entire delivery chain. For identity teams, the practical conclusion is simple: a control that ships and binds tokens in real paths is more valuable than one that remains architecturally pure.

Sender-constraining is becoming part of the identity blast-radius model. Once a token is bound to a key or certificate, compromise of the token alone no longer equals compromise of the session. That changes how teams think about secrets exposure, replay windows, and NHI credential handling. The practitioner takeaway is to evaluate where possession alone is still enough to move laterally, and remove those paths first.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, showing that machine access paths are expanding faster than most governance programmes.
• For a broader view of how secret exposure becomes identity risk, see Guide to the Secret Sprawl Challenge.

What this signals

Sender-constraining is a governance pattern, not just a protocol decision. Once access tokens can be bound to a client-held key or certificate, the remaining risk shifts to lifecycle, termination, and request-path control. That is especially relevant for service identities and API-driven workloads where replay can turn a single leak into broad lateral movement.

Identity teams should expect more hybrid token models. Some flows will continue to use mTLS because certificates are already operationalised, while others will need DPoP because TLS termination sits outside application control. The programme signal is clear: access governance is moving toward path-aware controls, not one-size-fits-all token handling.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, according to The State of Secrets Sprawl 2026, the next control discussion is not whether tokens leak, but whether leaked tokens can still be replayed. That is the difference between exposure and usable compromise, and it should shape how teams design API authentication.

For practitioners

• Map token replay exposure by client path Identify which OAuth flows still rely on bearer semantics, then classify them by browser, mobile, gateway-terminated, and backend-to-backend paths. Prioritise the flows where a stolen token can be replayed without any additional proof of possession.
• Use mTLS where certificates are already governable Apply certificate-bound tokens to machine-to-machine services that already have end-to-end TLS, predictable termination, and a managed certificate lifecycle. Keep issuance, thumbprint validation, and revocation in the same operational ownership chain.
• Adopt DPoP for clients that cross intermediaries Use HTTP-layer proof-of-possession for browser and mobile clients, or wherever API gateways and load balancers terminate TLS before the application server. Validate nonce freshness and request binding as part of request handling.
• Retire bearer-only assumptions in access reviews Treat unbound access tokens as a risk indicator in reviews for both NHI and user-facing integrations. Where replay would create material blast radius, move the design toward proof-of-possession rather than relying on token lifetime alone.

Key takeaways

• Bearer OAuth tokens remain replayable by design unless they are bound to the client that presents them.
• mTLS and DPoP solve the same security problem at different layers, which makes deployment context the deciding factor.
• Token Binding failed because ecosystem-wide adoption was unrealistic, proving that deployability is part of security design.

Key terms

• Sender-constrained token: An access token that only works when presented by the client that also proves possession of the matching key or certificate. This reduces replay risk if the token is stolen, copied, or exposed in logs. In practice, it turns token use into a two-part check: possession plus proof.
• Mutual TLS: A transport-layer identity pattern where both client and server present certificates during TLS negotiation. For OAuth, the token can be bound to the client certificate thumbprint, so the token alone is not enough to authenticate. It is strongest in controlled machine-to-machine paths with managed certificate operations.
• DPoP: Demonstrating Proof of Possession is an HTTP-layer method that attaches a signed proof to each request. The proof ties the token to a client-held key and to the specific request details, which makes replay harder even when TLS terminates at gateways or proxies. It suits browsers and mobile clients better than transport-bound methods.
• Token Binding: A now-abandoned protocol that tried to bind tokens to a specific TLS session and key material inside the transport stack. It failed less because the cryptography was wrong than because deployment required too many ecosystem participants to upgrade together. That makes it a useful cautionary example for modern identity design.

Deepen your knowledge

Sender-constrained tokens, mTLS, and DPoP are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are redesigning API access around replay resistance, this course fits that stage of the programme.

This post draws on content published by WorkOS: Sender-constrained tokens and what Token Binding failed to teach. Read the original.