Proof Key for Code Exchange (PKCE)

PKCE was created to mitigate a specific OAuth 2.0 vulnerability: the authorization code interception attack. In the standard Authorization Code flow, a malicious actor could potentially steal the short-lived authorization code as it is transmitted back to the client (e.g., via a malicious browser plugin or by logging the URI). If the attacker can intercept this code and use it before the legitimate client does, they can obtain an access token. PKCE makes this stolen code useless by cryptographically binding it to a secret only the legitimate client knows.

PKCE introduces two cryptographically linked values:

• Code Verifier: A high-entropy cryptographically random string created by the client. It is typically a 43-128 character string using characters [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~".
• Code Challenge: A transformed version of the Code Verifier. The client sends this to the authorization server during the initial authorization request. The transformation is either a plain S256 (SHA-256 hash, Base64URL-encoded) or plain (no transformation). S256 is mandatory for public clients in standards like OAuth 2.1. This pair creates a proof-of-possession mechanism for the authorization code.

PKCE modifies the OAuth flow in two key steps:

1. Authorization Request: The client generates a Code Verifier and derives a Code Challenge. It sends the Code Challenge (and the code_challenge_method, e.g., S256) to the authorization server along with the standard OAuth parameters. The server stores this challenge.
2. Token Request: When the client receives the authorization code, it makes the token request to the authorization server's token endpoint. This request must include the original Code Verifier. The server recalculates the Code Challenge from the provided verifier and compares it to the stored challenge. Only if they match is the authorization code considered valid, and an access token is issued.

PKCE is fundamentally designed for public clients where the use of a static client secret is insecure. This includes:

• Native Mobile Applications: Code and resources can be decompiled, making embedded secrets insecure.
• Single-Page Applications (SPAs): All application code, including any client secret, is executed in the user's browser and is therefore publicly viewable.
• Desktop Applications: Similar to mobile apps, they cannot protect a secret from a determined user. For these clients, PKCE provides the missing proof-of-possession element that a client secret would provide for a confidential server-side application.

Due to its critical security role, PKCE has evolved from a recommendation to a requirement in modern security profiles:

• OAuth 2.1: The in-progress revision of OAuth 2.0 makes PKCE mandatory for the Authorization Code flow for all clients, effectively deprecating the plain flow without PKCE.
• Financial-grade API (FAPI): This high-security profile mandates the use of PKCE with the S256 challenge method.
• Major Identity Providers: Services like Auth0, Okta, Microsoft Identity Platform, and others strongly recommend or require PKCE for public client flows, and it is the default for their SDKs.

PKCE is often discussed alongside other OAuth 2.0 extensions and best practices:

• Not a Replacement for Client Authentication: PKCE secures the code exchange but does not authenticate the client itself. For confidential clients, client authentication (e.g., client secret, private_key_jwt, mTLS) is still required at the token endpoint.
• Complementary to Refresh Tokens: PKCE protects the initial authorization code. If a refresh token is issued, it must also be protected, often by binding it to the client ID or using Refresh Token Rotation.
• Foundation for Advanced Flows: PKCE is a core component of newer, more secure patterns like the OAuth 2.0 Device Authorization Grant and is integral to BFF (Backend for Frontend) architectures that further isolate tokens from the browser.

This is the primary OAuth 2.0 flow that PKCE enhances. It involves a two-step exchange where a short-lived authorization code is returned to the client and then exchanged server-side for an access token.

• Traditional Use: Designed for confidential clients (web servers with a backend) where the client secret can be stored securely.
• PKCE's Role: PKCE adds a layer of security to this flow for public clients (SPAs, mobile apps) that cannot keep a secret, protecting against authorization code interception attacks.

This is the process by which an OAuth client proves its identity to the authorization server. PKCE provides an alternative mechanism for public clients that lack a traditional client secret.

• Methods: Client Secret, Private Key JWT, Mutual TLS.
• PKCE's Contribution: For public clients, the code verifier and code challenge serve as a form of proof-of-possession, binding the initial authorization request to the subsequent token request. This mitigates the risk of a stolen authorization code being used by a different client.

The access token obtained via a PKCE-augmented flow is typically a Bearer Token, as defined in RFC 6750. Anyone in possession of this token (the "bearer") can use it to access associated resources.

• Security Implication: Because bearer tokens are so powerful, the security of the flow that issues them (like PKCE) is paramount.
• Usage: The token is included in the Authorization HTTP header: Authorization: Bearer <token>.
• PKCE's Role: PKCE ensures that the entity receiving the bearer token is the same one that initiated the authorization request.

OpenID Connect is an identity layer built on OAuth 2.0. It uses the same flows, including PKCE, but adds an ID Token (a JWT) to convey verifiable user authentication information.

• Primary Output: While OAuth gives you an access token for APIs, OIDC gives you an ID token for the user's identity.
• PKCE Usage: PKCE is a mandatory security requirement for OIDC Native Apps and Single Page Apps using the Authorization Code Flow. This is specified in the OIDC Core and OAuth 2.0 for Native Apps best practices documents.