How should teams secure public OAuth clients that cannot hold bearer tokens safely?

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.

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.

Related resources from NHI Mgmt Group

• How should security teams govern sender-constrained OAuth tokens for public clients?
• How should teams secure bearer tokens in API and OAuth flows?
• What are the implications of using OAuth tokens in third-party integrations?
• What makes OAuth tokens risky in NHI environments?