PKCE Generator

Generate PKCE code verifier and challenge for OAuth 2.0

info

PKCE for OAuth 2.0 / OIDC

PKCE (Proof Key for Code Exchange) is used in OAuth 2.0 / OIDC authorization code flows to secure the exchange, especially for public clients like SPAs or mobile apps.
Challenge Method
128 chars
43 128
data_object

How to use in OAuth Flow

GET /authorize? response_type=code& client_id=...& code_challenge=......& code_challenge_method=S256
POST /token grant_type=authorization_code& code=...& client_id=...& code_verifier=......
Understanding PKCE (Proof Key for Code Exchange)
TL;DR

PKCE (pronounced 'pixy') is a security extension for the OAuth 2.0 Authorization Code flow. It prevents authorization code interception attacks by binding the authorization request to the token request using a cryptographic code verifier and challenge pair.

What is PKCE?

PKCE (Proof Key for Code Exchange, RFC 7636) is a security mechanism designed to protect the OAuth 2.0 Authorization Code flow from authorization code interception attacks. It is especially critical for public clients — applications like mobile apps and single-page applications that cannot securely store a client secret.

Without PKCE, a malicious app on the same device could intercept the authorization code returned by the identity provider and exchange it for an access token. PKCE prevents this by ensuring that only the application that initiated the authorization request can complete the token exchange.

How PKCE Works

The PKCE flow adds two parameters to the standard Authorization Code flow:

1. Before the Authorization Request

The client generates a random string called the code_verifier (43-128 characters, using unreserved URI characters). It then derives a code_challenge from it:

  • S256 method: code_challenge = BASE64URL(SHA256(code_verifier))
  • Plain method: code_challenge = code_verifier (not recommended)

2. Authorization Request

The client sends the code_challenge and code_challenge_method (S256 or plain) to the authorization server along with the standard authorization request parameters.

3. Token Request

After receiving the authorization code, the client sends the original code_verifier (not the challenge) to the token endpoint. The server computes the challenge from the verifier and compares it with the one received during authorization. If they match, the token is issued.

This ensures that even if an attacker intercepts the authorization code, they cannot exchange it without the original code_verifier.

Code Verifier Requirements

PropertyRequirement
Length43 to 128 characters
Character set[A-Z], [a-z], [0-9], -, ., _, ~
EntropyMust be cryptographically random

Common Use Cases

  • Single-Page Applications (SPAs): JavaScript apps running in the browser cannot hide a client_secret, making PKCE essential
  • Mobile applications: Native apps on iOS and Android use PKCE with custom URL schemes or universal links
  • CLI tools: Command-line applications that use the Authorization Code flow benefit from PKCE for secure token exchange
  • Confidential clients: Even server-side apps should use PKCE as defense-in-depth per OAuth 2.1 recommendations

Try These Examples

Generate New PKCE Pair Valid

Click to generate a fresh code_verifier and code_challenge pair using the recommended S256 method.

generate
Plain Method (Not Recommended) Invalid

The plain method sends the verifier as-is without hashing, which is less secure. Use S256 whenever possible.

plain

OIDC Authorization Code Flow with PKCE

Step 1 of 8
language User Agent
devices Client (SPA)
lock Auth Server
dns Resource Server
code_verifier = "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
SHA256(code_verifier)
code_challenge = "E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM"
code_challenge_method = "S256"
1

Generate PKCE

The Client Application generates a cryptographically random string called the code_verifier (43-128 characters, URL-safe). It then computes the code_challenge by applying SHA-256 hashing and base64url encoding to the verifier. The verifier is stored securely in memory — it will be needed later to prove the client's identity. This is the core of PKCE: even if an attacker intercepts the authorization code, they cannot exchange it without the original verifier.

Step 1 of 8