Use sender-constraining for any public client that can leak tokens through browsers, mobile storage, logs, or intermediaries. DPoP is the common application-layer option when client certificates are not practical. The key decision is whether the client can prove possession of a private key on every request, not whether the token is merely hidden.
Why bearer tokens are the wrong thing to expose in public clients
Public clients such as single-page apps and mobile apps cannot keep a bearer token secret for long, because the token can be copied from browser storage, debug logs, memory, proxies, or a compromised device. The practical consequence is simple: if theft and replay are plausible, token hiding is not enough, and the access token needs to be bound to something the attacker cannot also steal.
That is why sender-constraining matters. It changes the security property from “whoever has the token can use it” to “whoever has the token must also prove possession of the private key for this specific client instance.”
A useful way to think about it is that the client type determines what kind of proof is realistic. A public client usually cannot safely store a shared secret, so the design should move toward a proof-of-possession model rather than relying on obscurity or short-lived storage alone.
When DPoP is the practical choice
DPoP is often the most workable application-layer option when mutual TLS or client certificates are not practical for browser-based or mobile deployments. It lets the client sign each request with a private key and present a DPoP proof alongside the access token, which gives the authorization server and resource server a way to verify that the token is being used by the same client that obtained it.
That matters most when you cannot trust the browser sandbox, local storage, or every intermediary that can observe headers and requests. DPoP does not remove the need to protect the private key, but it does reduce the value of a stolen token because the attacker still lacks the proof key.
Teams should also distinguish between token binding and token audience control. Limiting token audience is helpful, but RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) addresses the stronger problem of replay by making the token presentation itself bound to possession of a key.
What secure public-client design should enforce
Secure design starts with the authorization flow and client posture, not with downstream compensating controls. Public clients should use modern OAuth flows, avoid reusable bearer material where possible, and treat refresh token handling as a high-risk design decision rather than a storage problem. If the client cannot protect long-lived secrets, the architecture should assume token exposure is a normal failure mode and design around it.
That is also where implementation details matter. Key generation, key storage, proof creation, and server-side verification must all line up, or the deployment only looks stronger on paper. If proof-of-possession is incomplete on either the token issuer side or the API side, replay resistance collapses at the weakest point.
For teams choosing the underlying protocol path, the baseline OAuth framework still matters. RFC 6749: The OAuth 2.0 Authorization Framework defines the grant and client model that DPoP and related protections build on, so the sender-constraining choice should be made inside a correctly implemented OAuth design, not as an afterthought.
Risk and Threat Considerations
Public clients are exposed to token replay, token exfiltration, and accidental disclosure through logs, browser state, mobile backups, or intercepted traffic. Once a bearer token is copied, an attacker does not need to compromise the client again, which makes replay a durable access path unless the token is sender-constrained.
Failure mechanism: The client relies on a bearer token that can be reused by anyone who obtains it, so theft turns into immediate API access with no cryptographic proof of client possession. If the token is also long-lived, the attacker gains a wider window for abuse.
Impact: Stolen tokens can enable unauthorized API calls, session hijacking, data exfiltration, and persistence that survives simple password resets or client reinstallations. In practice, the breach severity comes from how broadly the token can be replayed before revocation or expiry catches up.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Bearer token exposure and replay are core secret-leakage risks for public clients. |
| NHI-04 — Insecure Authentication | Public-client token use depends on proof-of-possession rather than bearer-only authentication. | |
| NHI-07 — Long-Lived Secrets | Long-lived access and refresh tokens increase replay value when public clients leak them. | |
| Recommendation — Reduce token exposure surfaces and bind sensitive access material to the client where possible. Require sender-constrained authentication for clients that cannot protect bearer tokens. Shorten secret lifetimes and prefer ephemeral credentials over durable bearer material. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Sender-constrained public clients need cryptographic proof when authenticating to APIs. |
| IA-5 — Authenticator Management | Token and key lifecycle controls are central when bearer material may leak from public clients. | |
| AC-6 — Least Privilege | Replayable tokens should have minimal authority to limit blast radius if exposed. | |
| Recommendation — Use cryptographic client authentication for non-human API callers that can prove possession. Manage token and key lifecycles to limit replay windows and revoke exposed credentials quickly. Minimize access scope so any stolen token has the smallest possible blast radius. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Stolen bearer tokens are replayable authentication material for APIs. |
| API3 — Broken Object Property Level Authorization | Token misuse often becomes overbroad data access when API authorization is weak. | |
| Recommendation — Harden API authentication so copied tokens cannot authenticate without possession proof. Pair stronger client authentication with object-level authorization checks on every request. | ||
Practitioner Guidance
What to prioritise: Prioritise sender-constraining wherever the client runs in an environment where token theft is plausible, and treat “public” as a storage constraint, not a reason to lower the security bar. If the client cannot safely hold a bearer token, the design should assume replay will happen unless a proof key is required on every request.
What to verify: Verify that the private key is generated and retained in a way that matches the client platform, that the access token is actually bound to that key, and that the resource server rejects requests without valid proof. A design that only constrains the front channel or only rotates tokens still leaves a replay path open.
Decision rule: If mTLS or certificate-bound tokens are operationally realistic, they can be strong choices; if they are not, use DPoP rather than falling back to bearer-token storage plus short expiration. The important decision is whether the client can prove possession, not whether the token was merely tucked away somewhere.
Practitioner takeaway: For public clients, the security goal is not to make bearer tokens harder to see, it is to make them useless without the client’s private key.