Notifications
Clear all
Topic starter
04/06/2026 6:45 pm
TL;DR: Bearer OAuth tokens remain vulnerable to replay unless they are sender-constrained, and WorkOS explains how mTLS and DPoP bind tokens to client-held keys while Token Binding failed because deployment required ecosystem-wide support. The real lesson is that security controls only matter when they can be adopted incrementally across existing infrastructure.
NHIMG editorial — based on content published by WorkOS: Sender-constrained tokens and what Token Binding failed to teach
By the numbers:
- Google removed Token Binding support entirely in Chrome 130 in 2024.
- DPoP has seen rapid adoption since its standardisation in 2023.
Questions worth separating out
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.
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.
Q: What do teams get wrong about sender-constrained tokens?
A: They often treat sender-constraining as a cryptography problem only.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
WorkOS's full analysis covers the operational detail this post intentionally leaves for the source:
- RFC-level comparison of mTLS, DPoP, and Token Binding implementation mechanics
- Detailed guidance on certificate thumbprints, cnf claims, and DPoP proof validation
- Browser, mobile, gateway, and backend deployment considerations for sender-constraining
- The practical trade-offs that determine which binding model fits your architecture
👉 Read WorkOS's analysis of sender-constrained tokens and token binding →
Sender-constrained tokens: are mTLS and DPoP enough for OAuth?
Explore further
04/06/2026 6:57 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Sender-constrained tokens and what Token Binding failed to teach
