# OAuth PKCE Verifier & Challenge

> Generate an OAuth 2.0 code_verifier and derive its S256 code_challenge, or paste your own and check it against RFC 7636's length and charset rules. The same SHA-256 base64url derivation your authorization server expects. Runs entirely in your browser.

- Tool: https://ronutz.com/en/tools/pkce
- Family: Identity & tokens

---

## What it does

Work with the two values at the heart of OAuth 2.0's PKCE extension. The tool generates a random `code_verifier` and derives its `code_challenge` using the S256 method, or takes a `code_verifier` you paste and checks it against the length and character rules of RFC 7636, deriving the same challenge your authorization server will expect. The derivation is the exact SHA-256 and Base64url step defined by the standard, and it all runs in your browser.

## What PKCE protects against

The OAuth 2.0 authorization-code flow sends a short-lived code back through the user's browser, and on a mobile or single-page app that redirect can be intercepted by another application. PKCE, "Proof Key for Code Exchange", closes that hole. At the start of the flow the client invents a secret, the `code_verifier`, and sends only a transformed version of it, the `code_challenge`, with the initial request. When it later exchanges the code for tokens, it presents the original `code_verifier`, and the server re-derives the challenge and checks that it matches. An attacker who steals the code cannot use it, because they never saw the verifier.

## The verifier and the challenge

- The **code_verifier** is a high-entropy random string of 43 to 128 characters, drawn from the unreserved set `A-Z a-z 0-9 - . _ ~`.
- The **code_challenge** is derived from it. The recommended method, `S256`, is `BASE64URL(SHA256(ASCII(verifier)))`, the Base64url encoding of the verifier's SHA-256 digest with no padding. The `plain` method, where the challenge simply equals the verifier, exists for constrained clients but is discouraged, because it offers no protection if the challenge is observed.

## Why it matters now

PKCE began as a fix for mobile apps but is now the baseline. The current OAuth security best practice, RFC 9700, requires PKCE for every client using the authorization-code flow, not just public ones. If you are building or debugging an OAuth client, generating a verifier and confirming its S256 challenge here lets you check your implementation against the specification directly.

## Using it

Generate a fresh `code_verifier` and read its `S256` `code_challenge`, or paste an existing verifier to validate its length and characters and derive the matching challenge. Because S256 is a one-way hash, the challenge reveals nothing about the verifier.

## Standards and references

- [RFC 7636 - Proof Key for Code Exchange (PKCE)](https://www.rfc-editor.org/rfc/rfc7636) - verifier, challenge, and S256 derivation
- [RFC 6749 - The OAuth 2.0 Authorization Framework](https://www.rfc-editor.org/rfc/rfc6749) - the authorization-code flow PKCE protects
- [RFC 9700 - Best Current Practice for OAuth 2.0 Security](https://www.rfc-editor.org/rfc/rfc9700) - PKCE required for authorization-code clients

## Related reading

- [Access tokens, refresh tokens, and ID tokens](https://ronutz.com/en/learn/oauth-tokens.md): Three OAuth and OpenID Connect tokens that get constantly confused, what each is actually for, and why sending the wrong one to the wrong place is a real bug.
- [OpenID Connect: identity on top of OAuth 2.0](https://ronutz.com/en/learn/openid-connect.md): How OIDC adds authentication to OAuth's authorization, what the ID token is, and why the code flow with PKCE is the recommended path.
- [PKCE: securing the OAuth authorization code flow](https://ronutz.com/en/learn/pkce.md): The interception attack PKCE defeats, how the verifier and challenge fit together, and why S256 is mandatory.
- [Public vs confidential clients, and where PKCE fits](https://ronutz.com/en/learn/oauth-client-types.md): Whether an OAuth client can keep a secret decides its whole security model. Why SPAs and mobile apps are public clients, and why PKCE is now recommended for all of them.
- [The OAuth 2.0 authorization code flow](https://ronutz.com/en/learn/oauth-code-flow.md): The four roles, the redirect-and-exchange dance, and why the code is swapped for a token on the back channel.