Notifications
Clear all
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.
NHIMG editorial — based on content published by WorkOS: DPoP explained and how sender-constrained OAuth tokens change token theft risk
By the numbers:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
Questions worth separating out
Q: How should security teams govern sender-constrained OAuth tokens for public clients?
A: They should treat sender constraining as a mandatory design control for any client that can leak bearer tokens, especially browsers, mobile apps, and AI agents.
Q: When does DPoP add more value than bearer-token rotation alone?
A: DPoP adds more value when token theft is plausible through logs, extensions, proxies, or script execution, because rotation still assumes the attacker can use the token until it expires.
Q: What breaks if browser private keys are stored badly for DPoP?
A: If the key is extractable or stored as plain text, an attacker who gains client-side access can exfiltrate the proofing key and turn DPoP into ordinary bearer-token risk again.
Practitioner guidance
- Map every public OAuth client to a sender-constraining decision Classify SPAs, mobile apps, and agent-facing clients separately from confidential server-to-server apps, then decide where DPoP or mTLS is required before token issuance is allowed.
- Store browser private keys as non-extractable Web Crypto objects Persist CryptoKey pairs in IndexedDB, not localStorage, and verify that the signing key cannot be exported even if JavaScript execution is compromised.
- Validate replay, nonce, and audience checks at the resource layer Require htm, htu, ath, jti, and nonce validation on every protected endpoint so a stolen token cannot be replayed across requests or services.
What's in the full article
WorkOS's full article covers the implementation detail this post intentionally leaves for the source:
- Walkthrough of the DPoP proof JWT structure, including htm, htu, ath, jti, and iat checks.
- Browser and mobile key-storage patterns for non-extractable private keys and nonce handling.
- Server-side validation steps for authorization servers and resource servers, including replay detection.
- Where DPoP fits next to mTLS, PKCE, PAR, OAuth 2.1, and MCP in public-client hardening.
👉 Read WorkOS's explanation of DPoP sender-constrained OAuth tokens →
DPoP and sender-constrained tokens: are your controls ready?
Explore further
06/06/2026 3:57 am
Sender-constrained OAuth is becoming the new baseline for public clients: Bearer tokens fail the moment a client environment can leak strings, which is exactly why browser extensions, logs, and proxies keep appearing in post-mortems. DPoP does not eliminate exposure, but it makes stolen tokens materially less useful because authority is no longer transferable by possession alone. That shifts OAuth governance from token secrecy to proof-of-possession assurance. Practitioner conclusion: public-client access models now need sender-constraining as a design assumption, not an exception.
A few things that frame the scale:
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits, according to the 2025 State of NHIs and Secrets in Cybersecurity.
- 91% of former employee tokens remain active after offboarding, which shows why possession-based access controls keep failing when lifecycle governance is incomplete.
A question worth separating out:
Q: Who should own DPoP and sender-constrained token governance?
A: Ownership should sit jointly with identity security, application platform teams, and the teams managing public clients. The reason is that DPoP spans token issuance, proof validation, browser or mobile key storage, and client lifecycle decisions, so no single control domain can govern it alone.
👉 Read our full editorial: DPoP sender-constrained tokens change the OAuth theft model
