Proof of possession
Bound to the client’s key
Each token is tied to the client’s public key. Using it needs a fresh proof signed with the private key.
Features / Token security
DPoP for Access and Refresh Tokens
A bearer token works for whoever holds it. With DPoP (RFC 9449), WebFrolic binds access and refresh tokens to a key held by the client, so a token that leaks from a log, a proxy or a compromised browser cannot be replayed without that key. You turn it on once, then decide per application which tokens must be bound.
Available now in WebFrolic.
Why it matters
Bearer tokens are only as safe as every place they pass through.
Tokens end up in browser storage, mobile devices, logs and agent runtimes. Refresh tokens are the bigger prize because they keep working for a long time. Sender-constrained tokens mean a copied token alone is no longer enough.
Per application
Access, refresh or both
Require DPoP only where it fits: the refresh token for a browser app, both tokens for a high-risk API client.
Standards-based
RFC 9449
Resource servers check the proof and the cnf.jkt thumbprint in the token, using standard DPoP libraries.
The building blocks
Where DPoP fits.
Applications
Browser and mobile apps
Public clients cannot keep a client secret. Binding the refresh token to a device key stops a stolen refresh token being used elsewhere.
Explore ↗Authorization
Your APIs
Your APIs can require DPoP-bound access tokens issued by WebFrolic and reject plain bearer tokens.
Explore ↗Agentic AI
AI agents
Agents that hold tokens for long-running work can prove possession on every call.
Explore ↗Protocols
PKCE by default
PKCE protects the authorization code; DPoP protects the tokens that come after it.
Explore ↗Enable DPoP
In Configuration → General → Advanced, turn on DPoP for the identity provider.
Choose per application
On each OAuth2 application, require DPoP for the access token, the refresh token or both. Applications you leave alone keep their current behavior.
Validate at the API
Have resource servers check the DPoP proof and the key thumbprint in the token, and reject bearer use where you require binding.
Before rollout
Questions worth answering.
Settle these first and the rollout is mostly configuration.
- List the clients that can create and protect a key pair, such as browser apps, mobile apps, servers and agents.
- Start with refresh tokens for public clients, where a leaked token does the most damage.
- Check that each API you protect can validate DPoP proofs before you require bound access tokens.
- Plan how clients handle a DPoP nonce challenge and clock skew.
- Decide what happens when a client loses its key: the user signs in again, and new tokens are bound to the new key.
Related capabilities
Explore what connects to this.
These capabilities are usually configured together.
Evaluate with your scenario
Start with a concrete workflow.
Share the identities, resource boundary and decision you want to test. The walkthrough can focus on the relevant behavior rather than a generic feature tour.