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.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Sender-constrained tokens: Why mTLS and DPoP exist, and what killed Token Binding”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Bearer OAuth tokens remain replayable unless the resource server can verify proof-of-possession at the point of use.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
04/06/2026 6:57 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Sender-constrained tokens and what Token Binding failed to teach