The DPoP Storage Paradox: Why Browser-Based Proof-of-Possession Remains an Unsolved Problem

The DPoP (Demonstrating Proof-of-Possession) specification represents a significant advancement in OAuth 2.0 security, addressing the well-known vulnerability of bearer tokens that can be used by anyone who possesses them. As outlined in RFC 9449, DPoP prevents token replay attacks by binding access tokens to a client's asymmetric key pair. Each request includes a fresh proof JWT signed by the client's private key, which the resource server validates before honoring the request.

However, as teams implement DPoP in browser-based applications, they encounter a fundamental paradox: the specification provides no guidance on where to store private keys in browsers, creating security vulnerabilities that practitioners must solve themselves. This challenge becomes particularly acute when considering the different cloud providers' browser environments and their varying implementations of the Web Crypto API.

The Oracle Attack: A Fundamental Browser Constraint

The recommended approach for browser-based DPoP implementations involves storing non-extractable CryptoKey objects in IndexedDB, as suggested in draft-ietf-oauth-browser-based-apps-26. The Web Crypto API allows generating keys with extractable: false, preventing exportKey() operations from revealing raw key material.

The critical vulnerability lies in what this protection doesn't cover: the sign() operation. An XSS attacker doesn't need to extract a key to misuse it—they can simply invoke crypto.subtle.sign() with the stored CryptoKey handle, turning the browser's crypto subsystem into a signing oracle. This enables attackers to generate valid DPoP proofs for arbitrary requests without ever accessing the raw private key bytes.

Cross-browser inconsistencies exacerbate this problem. Firefox cannot store CryptoKey objects in IndexedDB at all, forcing developers to use extractable keys that completely defeat the security model. Meanwhile, some browsers drop IndexedDB data in private browsing modes, adding another failure path for key persistence.

Provider Comparison: Browser Crypto Implementations

When evaluating cloud providers' browser environments for DPoP implementation, several key differences emerge:

• Chrome/Chromium: Supports non-extractable CryptoKey storage in IndexedDB but remains vulnerable to the Oracle Attack. Chrome's implementation of Trusted Types provides some defense-in-depth against XSS but doesn't solve the core cryptographic vulnerability.

• Firefox: Cannot store CryptoKey objects in IndexedDB, forcing extractable key storage that offers no meaningful protection against the Oracle Attack. Firefox's delayed adoption of modern web security features like Trusted Types mirrors this limitation.

• Safari: Implements Web Crypto API with similar constraints to Chrome, though its private relay feature adds additional network-layer protections that indirectly reduce certain attack surfaces.

These differences create significant implementation challenges for teams building cross-browser DPoP solutions, particularly when considering migration paths between cloud providers or hybrid deployments.

The BFF Pattern: Industry Standard Solution

The Backend-for-Frontend (BFF) pattern has emerged as the de facto solution for browser-based DPoP implementations. This approach shifts the trust boundary by:

1. Making the BFF a confidential OAuth client rather than the browser
2. Generating DPoP key pairs in server-side memory
3. Handling token management and proof generation server-side
4. Using HTTP-only, Secure, SameSite cookies for session management

This pattern provides categorical security improvements:

• XSS on the SPA cannot forge DPoP proofs without server credentials
• Prevents the fresh token acquisition attack where XSS mints new tokens
• Eliminates the need for browser-based key storage entirely

Major frameworks now support this pattern: Duende for .NET, Spring Cloud Gateway for Java, and Auth.js for Node.js. Cloud providers are also adapting: Keycloak 26.4 supports selective refresh-token-only DPoP binding, reducing per-request overhead while protecting sensitive credentials.

The trade-offs are measurable: BFF adds infrastructure complexity, introduces network latency, and reintroduces cookie-based CSRF considerations. For latency-sensitive applications or those with strict regulatory constraints around token handling, these factors may outweigh security benefits.

Memory-Only Approach: For Constrained Deployments

In scenarios where BFF deployment is infeasible—such as browser extensions, embedded widgets, or CDN-only infrastructure—a memory-only approach offers an alternative:

• Generate DPoP key pairs with extractable: false
• Store keys only in JavaScript module-scoped variables
• Implement "Lazy Re-Binding" to handle key rotation on page reload
• Combine with strict Content Security Policy

This approach limits the Oracle Attack blast radius to the current browser session, as keys cannot persist across page reloads. However, it doesn't prevent the fresh token acquisition attack and requires multi-tab coordination mechanisms like BroadcastChannel or SharedWorker.

Authorization server support for DPoP key rotation remains a prerequisite. While draft-rosomakho-oauth-dpop-rt-00 outlines mechanisms for this capability, widespread implementation is still emerging.

Business Impact and Migration Considerations

Organizations implementing DPoP must weigh several factors:

Security Posture: The BFF pattern provides the strongest security guarantee but requires mature infrastructure. For organizations handling sensitive data or operating under regulatory constraints, this may be non-negotiable.

Operational Complexity: BFF deployments require additional monitoring, scaling, and session management. Teams must evaluate whether existing infrastructure supports this pattern or if new cloud resources are needed.

Deployment Constraints: Browser extensions, embedded third-party widgets, or offline-first applications may necessitate the memory-only approach despite its security trade-offs.

Cloud Provider Considerations: Different providers offer varying levels of DPoP support in their identity services. Teams should evaluate whether their chosen provider's implementation aligns with their security requirements and migration timeline.

Future Directions

The ecosystem is evolving to address these challenges:

• Device Bound Session Credentials (DBSC) demonstrates TPM-backed key isolation in Chrome trials
• The W3C's Web Cryptography Level 2 extends the API but adds no dedicated key isolation mechanism
• Authorization server support for DPoP key rotation continues to expand

Until these developments mature, organizations must make deliberate architectural decisions based on their specific threat models and deployment constraints. The DPoP storage paradox has no universal solution—only approaches that balance security requirements with operational realities.