Sender-constrained tokens and what Token Binding failed to teach

At a glance

What this is: This article explains sender-constrained tokens, showing how mTLS and DPoP prevent bearer token replay while Token Binding failed because it depended on broad ecosystem adoption.

Why it matters: IAM and platform teams should care because token replay remains a practical access-path risk, and the binding method they choose must fit browser, gateway, and certificate-management constraints.

Context

Bearer OAuth access tokens are bearer credentials, which means possession is enough to use them. That creates exposure when tokens leak from logs, intermediaries, redirects, or compromised services, especially where TLS is terminated before the application or where client authentication is weak.

Sender-constraining changes the trust model by binding a token to a client-held key, so the token is only useful when paired with proof of possession. In identity governance terms, this is a control over token presentation and replay, not a replacement for OAuth itself.

WorkOS frames the real lesson as deployment realism: security mechanisms that cannot be introduced incrementally across existing infrastructure tend to stall even when the cryptography is sound. That makes transport, application, and browser compatibility part of the control decision, not an implementation afterthought.

Key questions

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: Why are bearer OAuth tokens still risky after TLS is in place?

A: TLS protects the channel, but bearer tokens still remain usable by anyone who obtains them after issuance. If the token leaks from logs, redirects, intermediaries, or a compromised service, the attacker can replay it unless the token is sender-constrained and bound to a client-held key.

Q: What breaks when token binding depends on the whole ecosystem shipping support?

A: Deployment stalls. If browsers, TLS libraries, load balancers, proxies, and applications all have to change together, the control becomes too fragile to adopt incrementally. That is why strong cryptography can still fail in practice when operational compatibility is the real gating factor.

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.

Technical breakdown

Bearer tokens and replay risk

OAuth 2.0 access tokens are bearer credentials, so the resource server does not know whether the presenter is the legitimate client or an attacker who intercepted the token. That makes leakage from logs, SSRF paths, open redirects, or compromised intermediaries materially dangerous. Sender-constrained tokens add a cryptographic binding so the token alone is insufficient; the client must also prove possession of a private key associated with the issued token. The security gain is not secrecy of the token itself, but unusability without the matching proof.

Practical implication: treat replay resistance as a token design requirement, not only a transport security problem.

How mTLS binds OAuth tokens

Mutual TLS binds the access token to the client certificate at the transport layer. The authorization server stores the certificate thumbprint in the token, and the resource server checks that the presented TLS client certificate matches the thumbprint before accepting the token. Because the TLS stack handles the proof, application code changes are minimal. The trade-off is operational: end-to-end TLS termination is required, certificate lifecycle management must be reliable, and browser JavaScript cannot directly access the client certificate, which limits browser-based use cases.

Practical implication: use mTLS where you control both endpoints and can operationalise certificate lifecycle and TLS termination consistently.

How DPoP shifts proof to the application layer

DPoP moves proof-of-possession into HTTP headers using a signed proof JWT. The client generates an asymmetric key pair, signs each request with the method, URI, timestamp, and a nonce, and the authorization server embeds a hash of the public key in the token. The resource server then validates both the token and the proof on each request. Because the proof travels with ordinary HTTP traffic, DPoP works through gateways and load balancers and is usable in browsers, but it introduces nonce handling, clock skew, and per-request signature verification overhead.

Practical implication: use DPoP when browser, mobile, or proxy-heavy architectures make transport-layer binding impractical.

Threat narrative

Attacker objective: The attacker wants to reuse a stolen access token to call APIs or services without controlling the original client.

1. Entry occurs when an attacker intercepts a bearer OAuth token through logs, redirects, compromised intermediaries, or another leakage path.
2. Credential abuse follows because the token can be replayed by anyone who presents it, unless the server also requires sender proof tied to a client-held key.
3. Impact occurs when the stolen token is accepted as legitimate and grants access to the protected API or service as if the original client were present.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Bearer token replay remains a governance problem, not just a transport problem: OAuth access tokens still behave like cash when they are presented without a proof-of-possession requirement. That means the control question is who can replay the credential after interception, not merely whether the channel was encrypted. Practitioners should treat sender-constraining as part of token governance, not as an optional hardening layer.

Incremental deployability is the real adoption test for access controls: Token Binding failed because it required browser vendors, TLS stacks, load balancers, and applications to move together. That is a deployment assumption, not a cryptographic one, and it breaks most enterprise rollouts. The implication is that controls depending on whole-ecosystem synchronisation rarely survive contact with heterogeneous infrastructure.

mTLS and DPoP survive because they align with existing operational boundaries: mTLS fits controlled backend-to-backend estates, while DPoP fits browser and proxy-heavy paths. That split matters because identity governance must follow where the token is actually presented, not where architecture diagrams wish it lived. Practitioners should align proof mechanism with the client type and termination point, or enforcement will fragment.

Sender-constrained tokens are a better example of layered identity assurance than stronger authentication alone: The article shows that the important security question is not only whether a client authenticated, but whether the same client can still present the token later. That is a distinct assurance property, and it belongs in the same governance conversation as token issuance, rotation, and replay detection. Security teams should map it as a control over credential reuse.

Token Binding's failure defines the deployment realism gap: Security protocols that need universal client and infrastructure support before they help anyone create a dependency chain too brittle for production. The lesson for identity architecture is to prefer controls that can be adopted per client class and per path. Practitioners should evaluate future token-binding proposals against this reality before they standardise on them.

What this signals

Sender-constrained tokens are a replay-control decision, not a token-format detail: The practical question is whether a stolen token can still be used after it leaves the intended client context. Once teams separate issuance from presentation, controls like mTLS and DPoP become governance choices about where proof must be enforced.

Deployment realism should outrank theoretical elegance in identity architecture: Token Binding failed because it needed synchronized change across browsers, TLS libraries, and intermediaries. That pattern is familiar across identity security: controls that cannot be introduced path by path usually never become controls in production.

Client path and termination point now determine token strategy: Browser flows, mobile apps, and backend services do not need the same sender-constraining method. Practitioners should design for the path the token actually takes, then standardise the proof mechanism accordingly.

For practitioners

• Define token binding by client type Separate browser, mobile, and backend-to-backend paths before choosing a sender-constraining method, because the viable control differs by client class.
• Prefer DPoP where TLS terminates upstream Use DPoP for browser-based clients and proxy-heavy routes where gateways or load balancers terminate TLS before the application server.
• Use mTLS for controlled service calls Apply mTLS to service-to-service and regulated API flows where certificate lifecycle management and end-to-end TLS are already operationally feasible.
• Validate replay resistance in the token path Test whether a leaked access token can be reused after interception, and verify that the proof mechanism is enforced at the actual resource boundary.

Key takeaways

• Bearer OAuth tokens remain replayable unless the resource server can verify proof-of-possession at the point of use.
• The article shows that mTLS and DPoP solve the same problem through different layers, which makes client type and TLS termination the deciding factors.
• Token Binding failed because adoption required broad ecosystem support, proving that incremental deployability is part of the security control itself.

Key terms

• Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
• Sender-constrained token: A sender-constrained token is tied to a specific client or cryptographic proof, rather than being usable by anyone who steals it. This reduces replay risk and is especially important where tokens can reach automation, services, or agents with broad API access.
• Proof-of-Possession: Proof-of-possession binds a token or credential to a specific key so possession of the token alone is not enough to use it. For AI agents, it reduces replay risk and helps ensure that an intercepted credential cannot be reused by a different actor.
• Token Binding: Token binding links a token to a specific device, certificate, or connection so it cannot be reused elsewhere without the bound proof. It reduces replay risk by making theft alone insufficient, although it does not remove the need for monitoring and revocation.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.