The Deprecation of the OAuth 2.0 Implicit Grant

In the early design of OAuth 2.0 (RFC 6749), Single Page Applications (SPAs) executing in browser JavaScript engines and native mobile applications were classified as public clients. Because public clients cannot securely store cryptographic credentials on end-user hardware without exposure to reverse-engineering, browser developer consoles, or decompilation tools, they could not maintain a confidential client_secret.

To accommodate public clients, OAuth 2.0 introduced the Implicit Grant Flow. Under this flow, the authorization server returned the Bearer Access Token directly in the URI hash fragment (#access_token=...) upon user login. Over a decade of operational security audits exposed fatal vulnerabilities in this approach:

  1. Browser History Logging: Fragment identifiers remain exposed in browser navigation history caches, web proxy access logs, and Referer headers transmitted to third-party scripts.
  2. Open Redirector Interception: Malicious redirect loops or Cross-Site Scripting (XSS) attacks could extract plain access tokens directly from the browser window object without authentication challenge.
  3. No Proof of Client Possession: Anyone intercepting the token could immediately impersonate the authenticated session without establishing that they initiated the login ceremony.

Consequently, the IETF OAuth 2.0 for Browser-Based Apps and OAuth 2.0 Security Best Current Practice (BCP) officially deprecated the Implicit Grant in favor of the Authorization Code Grant with Proof Key for Code Exchange (PKCE).

How PKCE Works: Mathematical Mechanics

PKCE (pronounced "pixie", RFC 7636) eliminates the need for a static pre-shared client secret by dynamically creating a cryptographically bound one-time secret for every single authentication request. The handshake proceeds in four deterministic steps:

+--------------------------------------------------------------------------+
|                     OAuth 2.0 with PKCE Architecture                     |
|                                                                          |
|  [Client Browser]                                  [Auth Server]         |
|         |                                                |               |
|  1. Generate code_verifier (random cryptographic string) |               |
|     Compute code_challenge = Base64URL(SHA-256(verifier))|               |
|         |                                                |               |
|  2. GET /authorize?code_challenge=xyz&method=S256 ──────>|               |
|         |                                                | (Stores chal) |
|         |<───── Returns Auth Code in Query Param ────────┤               |
|         |                                                |               |
|  3. POST /token {code, code_verifier} ──────────────────>|               |
|         |                                                | (Verifies:    |
|         |                                                | SHA256(verif) |
|         |                                                | == challenge) |
|         |<───── Returns Access & Refresh Tokens ─────────┤               |
+--------------------------------------------------------------------------+

Step 1: Generating the Code Verifier

The client application uses cryptographically secure random number generators (e.g., crypto.getRandomValues() in the Web Crypto API) to generate a high-entropy string:

  • Character set: [A-Z], [a-z], [0-9], -, ., _, ~.
  • Minimum length: 43 characters; maximum length: 128 characters.

Step 2: Deriving the Code Challenge

The client computes the cryptographic hash of the verifier using SHA-256 and encodes it using URL-safe Base64 without padding: $$\text{code_challenge} = \text{Base64URLEncode}(\text{SHA-256}(\text{code_verifier}))$$ The client persists the code_verifier in ephemeral session storage and directs the user agent to the authorization server with parameters: response_type=code, code_challenge=<challenge>, and code_challenge_method=S256.

Step 3: Authorization Code Issuance

The authorization server validates user identity (via credentials, multi-factor tokens, or SSO federation), records the associated code_challenge, and redirects back to the registered redirect_uri with a short-lived authorization code.

Step 4: Token Redemption and Server-Side Validation

The client makes an HTTP POST request to the token endpoint transmitting:

  • The received authorization code;
  • The original unhashed code_verifier.

The authorization server performs SHA-256 hashing on the incoming code_verifier and compares it against the stored code_challenge. If an eavesdropper intercepted the authorization code in transit, they cannot redeem it for tokens because they do not possess the private code_verifier held only within the initiating browser session.

Storage and Token Lifecycle in the Browser

Securing tokens after exchange requires strict storage discipline:

  • Never Store in localStorage: Persistent local storage is universally readable by any JavaScript running in the same origin, making tokens accessible to compromised NPM packages or XSS vulnerabilities.
  • Prefer BFF (Backend-For-Frontend) Architecture: The gold-standard enterprise design routes SPA traffic through a lightweight reverse proxy or server-side API gateway. The BFF manages the OAuth exchange, stores tokens in encrypted server-side session memory, and sets an HttpOnly, Secure, SameSite=Strict cookie on the client browser.
  • In-Memory Storage with Refresh Token Rotation: If an independent SPA must manage tokens directly in the client without a BFF, keep tokens exclusively in private closure memory (JavaScript runtime variables). When refreshing expired tokens, enforce Refresh Token Rotation, where the server issues a new refresh token with each renewal and revokes the entire authorization family if an old token is reused.