Topic starter
06/06/2026 2:20 am
TL;DR: DPoP, standardised in RFC 9449, binds OAuth tokens to a client-held key and requires a fresh proof JWT on each request, making stolen bearer tokens unusable without the matching private key, according to WorkOS. That changes token theft from a simple replay problem into a key custody and proof-validation problem that IAM, NHI, and agentic OAuth designs now have to account for.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “DPoP (RFC 9449) explained: How sender-constrained OAuth tokens make token theft a non-event”.
Key questions
Q: How should teams secure public OAuth clients that cannot hold bearer tokens safely?
A: Use sender-constraining for any public client that can leak tokens through browsers, mobile storage, logs, or intermediaries.
Q: Why do stolen OAuth tokens stop being immediately useful under DPoP?
A: Because the access token is bound to a specific client key, a stolen string does not authorise access unless the attacker can also sign the required proof JWT.
Q: What are the signs that a DPoP deployment is failing in practice?
A: Common signs include proof replays that are accepted, mismatched request method or URI checks, weak nonce handling, or private keys stored in extractable form.
Practitioner guidance
- Harden public OAuth clients with sender-constraining Require DPoP or an equivalent sender-constraining mechanism for browser apps, mobile clients, and other public clients that cannot safely hold bearer tokens.
- Store client keys as non-extractable material Use browser or platform key stores that keep the private key non-extractable and bound to the device or runtime.
- Enforce proof validation on every resource request Check the DPoP signature, the request method, the request URI, the access-token hash, the key thumbprint, and replay indicators before granting access.
Bottom line: DPoP changes OAuth from bearer-token possession to proof-bound access, which makes replayed tokens ineffective without the matching private key.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 12 hours ago by NHI Mgmt Group
06/06/2026 3:57 am
Bearer-token replay is no longer the right mental model for high-risk public OAuth clients. DPoP replaces pure possession-based access with a proof-of-possession requirement, which changes the governance problem from token leakage alone to token-plus-key custody. That matters most where clients cannot be fully trusted, such as browsers, mobile apps, and AI agents acting as public clients. Practitioners should treat sender-constraining as part of the access model, not as an afterthought.
A few things that frame the scale:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
A question worth separating out:
Q: When should organisations choose DPoP instead of mutual TLS?
A: Choose DPoP when the client is a browser, mobile app, or other public client that cannot realistically manage certificates. Choose mutual TLS when you control the transport and certificate lifecycle, especially in server-to-server environments. The tradeoff is client fit versus transport strength, not just implementation preference.
👉 Read our full editorial: DPoP sender-constrained tokens change the OAuth theft model
This post was modified 12 hours ago by NHI Mgmt Group