Loading Techie Utils…

PKCE Code Generator

Generate an OAuth PKCE code verifier and challenge, with state and nonce. Free, and runs entirely in your browser — nothing is uploaded.

About OAuth 2.0 / OIDC Helper

Almost nothing in an authorization flow is secret. The client id is public, the redirect URI is public, the scopes are public. All of the protocol's safety rests on three short strings: state, which ties a response to the request that started it; nonce, which stops an ID token being replayed into another session; and PKCE's code_verifier, which stops an intercepted authorization code being redeemed by whoever intercepted it.

Every one of them fails silently. A login that never compares the returned state works perfectly — for you and for an attacker feeding you their own response. A code_challenge computed over the wrong bytes produces a plausible base64url string and only fails at the token endpoint, with invalid_grant and no further explanation. So this builds the parameters correctly, and — more usefully — takes a verifier and challenge you already have and says whether they actually correspond.

It covers the rest of the round trip too: the provider's discovery document, read for what it actually permits rather than what it lists; the token request for all four grants, as a curl command you can run; the ID token that comes back, checked against the issuer, audience and nonce you asked for; the error that arrives instead, with what usually causes that particular code; and two redirect URIs compared character by character, which is what a provider does and why redirect_uri_mismatch is so often a trailing slash. Nothing here contacts a provider, and nothing pasted here leaves the tab.

Where it helps

  • Checks a verifier and challenge against each other, which is the question behind most PKCE debugging.
  • Checks an ID token the way a relying party has to: issuer, audience, expiry and the nonce from your own request.
  • Reads a discovery document for what it permits — S256, the implicit flow, whether anything can be revoked.
  • Names what differs between a registered redirect URI and the one being sent, which is what redirect_uri_mismatch will not tell you.
  • Builds the token request for all four grants as a curl command, so the failing exchange can be run by hand.
  • Everything is computed in this tab; no authorization server is contacted and no credential is transmitted.

Limits

  • It cannot tell you whether a real provider agrees — only what the specification requires.
  • It does not verify ID token signatures; use the JWT tool for that, with the key from the provider's jwks_uri.
  • A client secret can be typed in to complete a curl command, and stays in this tab — but a secret belongs on a server, and one pasted anywhere is one worth rotating.
  • Codes and tokens pasted here are shown shortened, but an authorization code in a bug report is a live credential until it expires.

Frequently asked questions

Why does my challenge not match my verifier?

Almost always because the SHA-256 was taken over the random bytes the verifier was generated from, rather than over the verifier string itself. The specification hashes the ASCII characters.

Do I need PKCE if I have a client secret?

Yes. Current guidance applies PKCE to every authorization code flow, confidential clients included — it defends against code interception, which a secret does not.

What should state be?

Unguessable random bytes, stored against the session, and compared on return. A timestamp or a counter defeats the mechanism entirely.

Is the implicit flow still acceptable?

No. It returns tokens in the URL fragment, where they land in history and anything reading the address bar. Use the authorization code flow with PKCE.

Why does redirect_uri_mismatch happen when the URI looks identical?

Because it is compared as a string. A trailing slash, http against https, a different port, an added query parameter — any of them is a mismatch. Paste both into the compare mode and it will name the difference.

Can I use an ID token to call my API?

No. An ID token is issued to the client to say who signed in; an access token is what an API accepts. Their audiences are different on purpose, and an API that accepts an ID token is accepting a token minted for somebody else's ear.

Should the token request go from the browser?

Only for a public client using PKCE, and only where the provider sends CORS headers for it. Anything holding a client secret must make that request from a server — which is why this shows a curl command rather than trying to send one.

Related tools

  • JWT — Read, verify and sign JSON Web Tokens
  • URL Encoder — Percent-encode components or whole URLs
  • Base64 — Encode or decode UTF-8 text and URL-safe Base64
  • Regex Tester — Test patterns, inspect groups and preview replacements
  • HTML Formatter — Indent and tidy HTML markup
  • CSS Formatter — Format stylesheets with consistent indentation

More Web Development tools