Architectural Trade-Offs of PKCE with Public Clients

Implementing Proof Key for Code Exchange (PKCE) with public clients—such as Single-Page Applications (SPAs)—enhances authentication security by preventing authorization code interception attacks without requiring a client secret. However, relying on browser-based public clients introduces critical architectural trade-offs regarding token persistence, cryptographic state management, attack surface exposure, and overall infrastructure complexity compared to confidential client patterns.

Security Gains vs. Client-Side Vulnerability

The primary advantage of PKCE (RFC 7636) for public clients is the elimination of static client secrets, which cannot be securely stored in distributed client-side code. By dynamically generating a high-entropy cryptographic random string (code_verifier) and its transformed counterpart (code_challenge), the client ensures that an intercepted authorization code cannot be exchanged for tokens without the original verifier.

The trade-off lies in the boundary of security: PKCE secures the token acquisition step, but it does not protect token storage. Once tokens are returned to a public web client, they exist within the browser runtime. This creates exposure to:

• Cross-Site Scripting (XSS): If tokens are stored in localStorage or sessionStorage, any injected script can read them. Storing tokens strictly in JavaScript memory limits persistence across page reloads and multiple tabs, often requiring complex silent renewal mechanisms (such as hidden iframes or refresh token rotation).
• Refresh Token Exposure: Providing refresh tokens to public clients carries significant risk. To mitigate this, identity providers (IdPs) must implement strict Refresh Token Rotation (RTR), invalidating the entire token family if a previously used token is re-submitted. This introduces state synchronization overhead across distributed authorization nodes.

Performance and Cryptographic Overhead

PKCE relies on standard cryptographic primitives, typically SHA-256 for the code_challenge calculation. In modern web environments, this depends on the browser's native Web Crypto API.

• Asynchronous Cryptography: The Web Crypto API (crypto.subtle) is asynchronous. Authentication initialization pipelines cannot run synchronously during initial script bootstrap, slightly increasing time-to-interactive during authentication flows.
• Fallback Complexity: If the target environment lacks secure cryptographic random number generation or Web Crypto support (such as certain embedded web views or legacy runtimes), the architecture must account for secure polyfills or fail safely.

State Persistence Across Navigation

The PKCE flow requires the code_verifier to persist between the initial authorization redirect to the Identity Provider and the subsequent callback redirect back to the application.

• Persistence Mechanisms: Architectures must store the unhashed code_verifier alongside a CSRF state parameter in temporary client-side storage (typically sessionStorage or an ephemeral cookie).
• Multi-Tab and Interrupted Flows: If a user initiates logins across multiple tabs or navigates away before completing the handshake, orphaned verifiers can cause state mismatches or race conditions, necessitating robust cleanup routines and defensive error handling.

PKCE (Direct to IdP) vs. The Backend-for-Frontend (BFF) Pattern

The most significant architectural decision involving PKCE in web development is choosing between a pure public client approach and delegating authentication to a Backend-for-Frontend (BFF).

Choosing a pure PKCE implementation reduces operational complexity by avoiding an intermediary backend tier, making it cost-effective and suitable for statically hosted frontends. However, this shifts the burden of token lifecycle management entirely onto the frontend.

Conversely, adopting a BFF pattern transforms the SPA into an interface backed by a confidential client. While the BFF still uses PKCE when communicating with the upstream authorization server, tokens never enter the browser execution context. This dramatically lowers the impact of XSS at the expense of maintaining, scaling, and monitoring an intermediary proxy layer.