Question #30 of 60•Security & Auth•Hard• ~3 min read

How does OAuth 2.0 PKCE secure Single Page Applications (SPAs) & Mobile Apps?

Executive Takeaway

Understand Proof Key for Code Exchange (PKCE), code verifiers, and code challenges to prevent authorization code interception attacks.

Architectural Breakdown & AnalysisFAANG Aligned

Public clients (React SPAs, Mobile Apps) cannot securely store Client Secrets. Standard Authorization Code Grant exposes them to interception attacks.

How PKCE Prevents Interception

  1. Code Verifier Generation: App generates a random high-entropy string (code_verifier).
  2. Code Challenge Creation: App hashes the verifier using SHA-256 (code_challenge = Base64(SHA256(code_verifier))).
  3. Authorization Request: Client sends user to Auth Server with code_challenge and code_challenge_method=S256.
  4. Token Exchange: When Auth Server returns the authorization_code, the app sends the original code_verifier. Auth Server hashes it and verifies match before issuing JWT tokens.
TIP — Security Standard

OAuth 2.0 Security Best Practices mandate PKCE for all SPA and mobile application authentication flows.

Key Architectural Comparison

OAuth 2.0 FlowSecurity VulnerabilityClient TypeToken Exposure RiskModern Status
Implicit GrantAccess token returned directly in URL hash.SPAs & Mobile.High (Token leaked in browser history/logs).Deprecated & Banned.
Auth Code (with Secret)Secret cannot be hidden on public clients.Backend Web Apps.Low (Token exchanged backchannel).Standard for server-side apps.
Auth Code + PKCECryptographic code verifier / challenge.SPAs & Mobile.Zero (Intercepted auth codes cannot be exchanged).Current Industry Standard.
Previous QuestionWhat are the trade-offs of Layer 4 vs Layer 7 Load Balancing (HAProxy vs Envoy)?Next Question Which caching pattern should you choose: Write-Through, Write-Back, or Cache-Aside?

Continue Learning on Being SDE

Explore deep-dive system architecture modules, low-level object-oriented designs, and interview cheat sheets.