OAuth 2.0 and OIDC Flow Visualizer and PKCE Generator - Authorization Code, Client Credentials, and S256 Challenge Builder

First Published:
Last Updated:

Visualize the main OAuth 2.0 and OpenID Connect authorization flows step by step, generate a PKCE code_verifier and S256 code_challenge, and assemble an authorization request URL - all entirely in your browser.

This tool visualizes OAuth 2.0 / OIDC flows and generates PKCE values entirely in your browser, following RFC 6749, RFC 7636, RFC 9700, and OpenID Connect Core 1.0 as of June 23, 2026. It does not contact any identity provider and does not perform a real authorization.

  • This tool is provided "AS IS" without any warranties of any kind.
  • It never sends a network request: it does not redirect, call any token endpoint, or transmit your inputs anywhere.
  • Generated values are for development and testing. Do not paste production client secrets into this or any online tool.
  • This tool does not verify tokens or signatures and is not a substitute for a security review of your identity provider configuration.
  • By using this tool, you accept full responsibility for any outcomes.

This tool uses client-side JavaScript for all processing. No data is transmitted to servers, no files are uploaded online, all processing happens locally in your browser. Once loaded, this tool continues to work even without an internet connection. For more details, please refer to our Web Tools Disclaimer.

Pick a grant type to see the participants, the ordered messages between them, and every request/response parameter with its RFC requirement level.

Generate an RFC 7636 code_verifier and its S256 code_challenge. The verifier is created from cryptographically random bytes using the Web Crypto API, then base64url-encoded; the challenge is the base64url of its SHA-256 hash.

RFC 7636 allows a verifier of 43 to 128 unreserved characters. 32 random bytes base64url-encoded gives the recommended 43 characters.

Assemble an authorization request URL for the front channel. The tool only builds and URL-encodes the string for you to copy - it never opens, redirects to, or sends the URL.

Examples:
The authorization server's /authorize endpoint (absolute http(s) URL).
Authorization servers match this by exact string (RFC 9700).
For OpenID Connect, include openid.
RECOMMENDED. An opaque value bound to the user agent for CSRF protection; the server echoes it back.
Included only if non-empty. Binds the returned id_token to this session to mitigate replay.
Generate it in the PKCE Generator tab, then click "Use this challenge in the URL Builder", or paste your own. Used only when PKCE is enabled above.

Features

  • Flow Visualizer: Step-by-step diagrams for Authorization Code + PKCE, OIDC Authorization Code, Client Credentials, and the deprecated Implicit grant, showing each participant and message.
  • Per-Step Parameter Tables: Every request and response parameter is listed with its RFC requirement level (REQUIRED / RECOMMENDED / OPTIONAL / PKCE) and a short description.
  • PKCE Generator: Creates a code_verifier from cryptographically random bytes (Web Crypto API) and computes the S256 code_challenge as base64url(SHA-256(verifier)), with selectable entropy from 43 up to 128 characters.
  • Authorization URL Builder: Assembles and URL-encodes an authorization request from your inputs, with one-click random state / nonce and optional PKCE parameters.
  • Deprecation Guidance: The Implicit grant is clearly labelled deprecated, and the builder warns when a non-code response type is selected.
  • Examples / Presets: One-click SPA (OIDC) and server-side web app templates for the URL builder.
  • 100% Client-Side: No fetch(), no redirects, no telemetry. Nothing leaves your browser.
  • Works Offline: Once loaded, the page and its single JS file work without an internet connection.
  • Zero Dependencies: Vanilla JavaScript using only the Web Crypto API.

How to Use

  1. Explore a flow. On the Flow Visualizer tab, pick a grant type. Read the ordered steps and the parameter tables to see exactly what is sent and returned.
  2. Generate PKCE values. On the PKCE Generator tab, choose the entropy and click Generate. Copy the code_verifier (keep it secret) and the code_challenge.
  3. Build an authorization URL. On the Authorization URL Builder tab, load an example or fill in your endpoint, client_id, redirect_uri, and scope. Generate a random state (and nonce for OIDC).
  4. Attach PKCE. Enable "Include PKCE" and use the challenge generated in step 2, then click Build Authorization URL and copy the result into your own client.
  5. Exchange the code yourself. This tool stops at building the request. Your application performs the real redirect and the back-channel token exchange (sending the code_verifier).

About This Tool

OAuth 2.0 (RFC 6749) is an authorization framework that lets a client obtain limited access to a resource server on behalf of a resource owner, without handling the owner's credentials. OpenID Connect Core 1.0 (OIDC Core) adds an identity layer on top, returning a signed id_token (a JWT) when the request includes the openid scope.

PKCE - Proof Key for Code Exchange (RFC 7636) - binds an authorization request to the client that started it by sending a hashed code_challenge up front and proving knowledge of the original code_verifier at the token endpoint. The OAuth 2.0 Security Best Current Practice (RFC 9700) requires public clients to use PKCE and recommends against the Implicit grant; the in-progress OAuth 2.1 effort consolidates the same guidance.

All parameter names, requirement levels, and the PKCE transformation shown here were verified against those primary sources on June 23, 2026. Referenced specifications: RFC 6749, RFC 7636, RFC 9700, and OpenID Connect Core 1.0.

Frequently Asked Questions

Why use PKCE?

PKCE protects the Authorization Code grant against authorization code injection and interception. Because the client commits to a code_challenge at the start and must present the matching code_verifier at the token endpoint, an attacker who steals the authorization code cannot redeem it. RFC 9700 requires public clients (SPAs, mobile/native apps) to use PKCE, and authorization servers must support it.

What is the difference between state and nonce?

state is an OAuth 2.0 value used for CSRF protection: the client binds it to the user agent and verifies the echoed value on the callback. nonce is an OpenID Connect value carried into the id_token and checked by the client to mitigate token replay and bind the ID Token to the session. They solve different problems, so a typical OIDC request includes both.

Which flow should I use for SPAs, mobile apps, or server-to-server?

For browser SPAs and mobile/native apps (public clients), use the Authorization Code flow with PKCE. For server-side web apps (confidential clients), use the Authorization Code flow with client authentication, plus PKCE as defense in depth. For machine-to-machine calls with no user present, use the Client Credentials grant.

Is the Implicit grant still recommended?

No. RFC 9700 states that clients SHOULD NOT use the Implicit grant (response type token) because it returns tokens in the URL fragment and issues no refresh token. Use Authorization Code + PKCE instead. Likewise, the Resource Owner Password Credentials grant MUST NOT be used.

Does this tool contact my identity provider or perform a real login?

No. Everything runs locally in your browser. The tool only visualizes flows, generates PKCE values, and builds a URL string. It never redirects, calls a token endpoint, or transmits your inputs. Your real application must perform the actual redirect and token exchange.

Related Tools

Important Notes

  • This tool visualizes OAuth 2.0 / OIDC flows and generates PKCE values entirely in your browser, following RFC 6749 / RFC 7636 / OIDC Core as of June 23, 2026. It does not contact any identity provider and does not perform a real authorization. Generated values are for development and testing; do not paste production client secrets.
  • PKCE generation uses the Web Crypto API (crypto.getRandomValues and crypto.subtle.digest('SHA-256')), which require a secure context (HTTPS). In an insecure context the PKCE generator is disabled.
  • A code_verifier must stay secret in the client and is sent only at the token endpoint - never in the authorization request. Only the code_challenge appears in the authorization request.
  • The "plain" PKCE method is allowed by RFC 7636 but should be avoided. If the client can use S256, it MUST use S256; this tool only generates S256 challenges.
  • The example messages in the Flow Visualizer are illustrative. Real values (codes, tokens, client secrets) come from your authorization server and are never generated or transmitted here.
  • Client secrets belong only to confidential clients on a trusted back end. Never embed a client secret in a browser SPA or a mobile app, and do not enter production secrets into this tool.
  • Requirement levels and parameter names shown here follow the cited RFCs. Individual identity providers may add their own required or optional parameters - always check your provider's documentation.

References:
Tech Blog with curated related content
Web Tools Collection

Written by Hidekazu Konishi