Proof Key for Code Exchange (PKCE)

The foundation of PKCE is the code verifier, a high-entropy cryptographic random string created by the client. The client then generates a code challenge by transforming the verifier (typically using the S256 SHA-256 hash). The challenge is sent to the authorization server during the initial request, while the verifier is kept secret. This binds the subsequent token request to the original authorization request.

• Code Verifier: A cryptographically random string of 43-128 characters (A-Z, a-z, 0-9, '-', '.', '_', '~').
• Code Challenge: The transformed verifier, sent as part of the initial /authorize request.

PKCE was created to defend against the authorization code interception attack, a primary threat to public clients (mobile apps, SPAs). In a standard OAuth flow without PKCE, an attacker who intercepts the authorization code can exchange it for tokens. PKCE prevents this because the attacker cannot generate a valid token request without the original, secret code verifier that corresponds to the code challenge sent initially. Even if the code is stolen from the redirect URI, it is useless without the verifier held by the legitimate client.

PKCE defines two transformation methods for creating the code challenge from the verifier:

• S256: The verifier is hashed with SHA-256, then Base64URL-encoded. This is the recommended and most secure method, as it never exposes the original verifier.
• plain: The verifier is used as the challenge without transformation. This method is provided for compatibility but should be avoided as it offers no security benefit if the challenge is observed. RFC 7636 mandates support for S256.

PKCE also provides a layer of defense in scenarios involving malicious or compromised client applications. If a malicious app registers a custom URI scheme also used by a legitimate app, it could potentially capture authorization codes. PKCE mitigates this risk because the malicious app would not possess the correct code verifier generated by the legitimate app at the start of its flow. This makes code replay attacks significantly more difficult.

PKCE is particularly critical for clients that cannot securely store a client secret, which includes:

• Single-Page Applications (SPAs): JavaScript running in the browser cannot protect a secret.
• Mobile & Desktop Native Apps: Apps distributed to end-user devices are considered 'public clients' as their embedded secrets can be extracted. For these clients, PKCE provides the primary proof that the entity redeeming an authorization code is the same one that initiated the request, effectively substituting for a client secret in the token request phase.

The importance of PKCE is underscored by its elevation in OAuth 2.1, which consolidates and simplifies the OAuth 2.0 specification. In OAuth 2.1:

• The Authorization Code Flow with PKCE is the required flow for all OAuth clients, whether public or confidential.
• The implicit grant and resource owner password credentials flows are removed.
• The authorization code flow without PKCE is deprecated. This change reflects the security industry's consensus that PKCE's benefits are essential for modern application security and should be universally adopted.

The OAuth 2.0 Authorization Code Grant is the flow secured by PKCE. It is a server-side, multi-step process designed to keep access tokens hidden from the user's browser and potential malicious actors.

• Standard Flow (without PKCE): The client redirects the user to the authorization server. After the user consents, the server redirects back to the client with a short-lived authorization code in the URL query string. The client then exchanges this code, along with its client secret, for an access token via a secure back-channel request.
• The Interception Risk: In a public client, there is no true client secret. An attacker who intercepts the authorization code (e.g., from browser history, logs, or a compromised redirect URI) could exchange it for an access token themselves. This is known as an Authorization Code Interception Attack.
• PKCE's Role: PKCE adds a cryptographically bound secret (the code verifier) to this flow, making the intercepted code useless without the original verifier known only to the legitimate client.

These are the two core cryptographic components introduced by PKCE.

• Code Verifier: A high-entropy cryptographically random string created by the client. It is typically 43-128 characters long, using characters [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~". The client must keep this secret.
• Code Challenge: A derived value sent to the authorization server during the initial authorization request. The client creates it by transforming the code verifier.
  • S256 Method (Recommended): The code challenge is the Base64URL-encoded SHA-256 hash of the code verifier. This prevents the original verifier from being exposed even if the challenge is intercepted.
  • plain Method: The code challenge is the verifier itself (not recommended unless S256 is unavailable).
• The Binding: When the client later exchanges the authorization code for a token, it must present the original code verifier. The authorization server recalculates the challenge from this verifier and compares it to the initial challenge it stored. A match proves this client initiated the original request.

A Public Client is any OAuth 2.0 client application that cannot securely store a client secret. This inability is inherent to its architecture, not a configuration choice.

• Examples: Native mobile apps (iOS, Android), single-page applications (SPA) running in a web browser, and desktop applications.
• The Security Problem: These clients execute in an environment controlled by the resource owner (the user's device/browser). Any embedded secret can be extracted through reverse engineering or debugging, making it not truly secret. Therefore, the traditional OAuth Authorization Code flow, which relies on a client secret for the code exchange, is insecure for them.
• PKCE as the Solution: PKCE was specifically designed to secure the Authorization Code flow for public clients without requiring a static client secret. It replaces the secret's function with the dynamically generated, transaction-specific code verifier, providing proof of origin for the token request.