PKCE: Securing Public Clients

Without PKCE, mobile applications are vulnerable to authorization code interception attacks. When the authorization server redirects the authorization code to the app's registered custom URI scheme (e.g., myapp://callback), any malicious app on the same device that registers the same URI scheme can intercept the redirect and steal the code.

The attack: a malicious app registers the same custom URI scheme as the legitimate app. When the authorization server redirects the code to myapp://callback, the OS may present both apps as handlers. If the user selects or the OS defaults to the malicious app, the attacker receives the authorization code and can exchange it for tokens without knowing the client secret.

PKCE (RFC 7636) adds a dynamically generated secret to the authorization code flow. Before initiating the flow, the client generates a cryptographically random string of 43-128 characters called the code verifier. This string is unique to each authorization request and is never transmitted until the token exchange step.

The client computes a code challenge from the verifier: code_challenge = BASE64URL(SHA256(code_verifier)). Using SHA256 is the required method in RFC 7636 (the "plain" method, which sends the verifier directly, is not recommended). The code challenge is a one-way transform of the verifier, meaning knowing the challenge does not reveal the verifier.

The authorization request includes two additional parameters: "code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256". The authorization server stores the code challenge associated with the issued authorization code. No secret is transmitted to the server that could be intercepted at this stage.

During the token exchange (POST to the token endpoint), the client includes "code_verifier=ORIGINAL_RANDOM_STRING" alongside the authorization code. The authorization server computes BASE64URL(SHA256(code_verifier)) and verifies it matches the stored code_challenge. Only the legitimate client that generated the verifier can pass this check.

If an attacker intercepts the authorization code, they receive only the code and the code challenge (which is public). To exchange the code for tokens, they must provide the code verifier. Since the verifier was generated by the legitimate client and never transmitted until the token exchange (which happens securely), the attacker cannot compute or retrieve the verifier.

PKCE also prevents authorization code injection attacks, where an attacker replaces a valid code with a stolen code in the redirect. The stolen code's challenge does not match the verifier the victim's client will present, causing the token exchange to fail. PKCE provides defense-in-depth against multiple attack vectors simultaneously.

Although RFC 7636 was initially described as a solution for public clients (those without client secrets), the OAuth Security BCP and OAuth 2.1 require PKCE for all clients, including confidential clients with client secrets. PKCE provides protection independent of client authentication, making it universally beneficial.

OAuth 2.1 (draft-ietf-oauth-v2-1) consolidates the security best practices from the OAuth 2.0 Security BCP into a single document. It mandates PKCE for all authorization code flows, deprecates the implicit flow, and requires refresh token rotation. PKCE is effectively the required baseline for any new OAuth 2.0 implementation.

Implementing PKCE correctly requires: using a cryptographically secure random generator for the verifier (at least 32 random bytes, then base64url-encoded), storing the verifier securely in the client (not in the URL or logs), using S256 method (not plain), and ensuring the verifier is discarded after the token exchange. Most modern OAuth libraries handle PKCE automatically.

In PKCE, what is the relationship between the code verifier and the code challenge?

PKCE (RFC 7636) prevents authorization code interception by binding each code to a dynamically generated code verifier known only to the legitimate client. The verifier is hashed to produce the code challenge (sent publicly). The token exchange requires the original verifier. PKCE prevents both interception and injection attacks. OAuth 2.1 mandates PKCE for all authorization code flows.