What is PKCE Flow?

Proof Key for Code Exchange (PKCE, pronounced "pixy") is an extension of the Authorization Code grant type.

The Authorization Code grant type is used by OAuth 2.0 confidential and public clients to exchange an authorization code for an access token.

However, OAuth 2.0 public clients using the Authorization Code grant type are susceptible to authorization code interception attacks. This occurs when an attacker intercepts the authorization code within the client's operating system, in communication paths that aren't protected by TLS. The PKCE flow mitigates this security risk.

PKCE Flow

The PKCE flow has 5 main steps:

Step 1: Client generates a code verifier and a code challenge

The client first creates a code verifier.

A code verifier is a cryptographic random string with a minimum length of 43 characters and maximum length of 128 characters. The code verifier should have high entropy (a high degree of randomness), so that it’s practically impossible for anyone to guess its value.

The client then derives a code challenge from the code verifier in 3 steps:

1. Converts the code verifier string into its byte form.
2. Converts the bytes into a fixed-length binary hash using the SHA256 algorithm (known as the code challenge method). This conversion is one-way, meaning you can't derive the original code verifier from the hash.
3. Converts the binary hash into a string with only URL-safe characters using base64url encoding.

Step 2: Client sends an Authorization Request

The client sends an Authorization Request to the Authorization Server. In the request, it includes two important pieces of information: the code challenge and the code challenge method. The Authorization Server stores both these pieces of information.

Step 3: Authorization Server issues an Authorization Code

The Authorization Server responds by issuing an authorization code. Note that the server typically stores the code challenge and the code challenge method in an encrypted form in the authorization code itself.

Step 4: Client sends an Access Token Request

The client proceeds to request an access token. This request includes the authorization code and the original code verifier (not the code challenge).

Step 5: Authorization Server issues an Access Token

Before issuing an access token, the Authorization Server verifies that the request for access token has come from the same client that made the initial authorization request. This verification happens in two steps:

1. The server takes the code verifier and transforms it into a code challenge using the code challenge method it had stored (alongside the original code challenge) in step 1.
2. The server then compares this newly generated code challenge with the original code challenge. If they match, proving it's the same client, the server issues an access token.

How PKCE flow prevents authorization code interception attacks

Let's say an attacker intercepts the authorization code. The attack would still fail, because they wouldn't be able to exchange the stolen authorization code for an access token without the corresponding code verifier (which remains with the legitimate client).

Important note about PKCE

While PKCE was originally designed to secure native applications (applications that are installed directly on a user’s devices such as a smartphone, or desktop and run natively on the operating system), it's now recommended for all types of OAuth clients (including confidential clients like server-side web applications) because it provides strong protection against authorization code interception attacks.

Last updated on Tuesday, February 4th, 2025