Zero Snippet

OAuth 2.0 flow visualizer — authorization code, PKCE, and token exchange

Use this free OAuth 2.0 flow visualizer to learn how the authorization code grant works end to end: the browser visits your authorization endpoint with response_type=code, the user signs in, the redirect carries an authorization code and state, and your app exchanges the code at the token endpoint for access tokens (and often a refresh token in confidential flows). Toggle PKCE to see code_verifier and code_challenge for public clients and SPAs. Everything runs locally—pair it with our JWT decoder for OIDC id_token inspection and the URL encoder when debugging redirect URIs.

Privacy: URLs and form bodies are built only in your browser. This page does not send your client secret or tokens to any server.

Authorization code flow (overview)

Follow the numbered steps. Use the highlight control to focus each phase while you read the generated URLs and curl example.

  1. Authorize

    User agent opens the authorization URL with response_type=code.

  2. Consent

    Resource owner signs in and approves scopes at the authorization server.

  3. Redirect

    Browser returns to redirect_uri with ?code=…&state=… (or ?error=…).

  4. Token

    Your backend or secure client POSTs the code to the token endpoint.

Endpoints & client

code_verifier
—
code_challenge (S256)
—

Step 1 — Authorization request URL

Open this URL in a browser only when testing your own authorization server—never send real user credentials through untrusted sites.

state is required (use a random value to prevent CSRF).

Step 2 — Redirect callback (paste query string or full URL)

state returned

—

Compare returned state with the value you stored before redirect.

Step 3 — Token exchange (application/x-www-form-urlencoded)

Enter an authorization code above to generate the POST body.

Why visualize OAuth 2.0 flows?

Teams implementing login, SSO, or API access tokens constantly revisit the same questions: which parameters belong on the authorize URL, how redirect_uri matching works, why state matters for CSRF, and when to add PKCE. A dedicated OAuth 2.0 debugging helper turns RFC prose into concrete strings you can diff against network traces, Postman collections, and framework logs—without sending credentials through a third-party backend.

This page focuses on the authorization code flow, which is the recommended pattern for web apps, mobile apps, and most OpenID Connect sign-in. Implicit and password grants are largely deprecated for new user-facing flows; if you maintain legacy clients, compare their parameters against what you generate here and migrate toward code + PKCE where possible.

How to use this OAuth 2.0 flow visualizer (step by step)

  1. Fill in your authorization endpoint and token endpoint from your provider's docs (Auth0, Okta, Azure AD, Keycloak, Cognito, or custom OIDC servers). Use Upload config JSON if you already saved a non-secret profile, or Load sample values to see the shape of each field.
  2. Set client_id, redirect_uri, and scope. The redirect URI must match your app registration exactly, including trailing slashes and scheme. Click New beside state for a fresh CSRF token per attempt.
  3. Keep PKCE enabled for public clients. Copy the authorization request URL only when testing against your own authorization server—never ask end users to sign in to production accounts on untrusted domains.
  4. After redirect, paste the full callback URL or query string. The tool extracts the code and shows the returned state so you can verify it matches what you stored before redirect.
  5. Optionally add a client_secret for confidential server-side clients. Copy the application/x-www-form-urlencoded body or the curl example and run it from your machine or paste into the HTTP request builder.

Keywords: OAuth 2.0 authorization code, PKCE, and OpenID Connect

Engineers search for OAuth 2.0 authorization code flow explained, PKCE code_challenge, OAuth redirect_uri mismatch, and OpenID Connect token endpoint when integrating identity providers. This tool surfaces those pieces explicitly: response_type=code, state, code_challenge_method=S256, and the token request body with grant_type=authorization_code. For JSON token responses, use the JSON formatter and API response formatter to pretty-print responses from your token endpoint.

Security notes for production OAuth deployments

Treat this page as a teaching and debugging aid: it does not validate tokens, enforce TLS, or implement your provider's quirks (JWT client assertions, mTLS, or PAR). Never embed live client secrets in front-end apps; keep secrets on the server, rotate them, and use short-lived access tokens. When you issue or verify JWTs yourself, cross-check algorithms and signing keys with the JWT encoder in controlled test environments only.

Related API and developer tools

Browse the full API developer toolbox on the home page. Highlights:

  • HTTP Request Builder — Test, document, and debug APIs without leaving the browser—pick method, headers, and body, then send with fetch.
  • API Response Formatter — Paste any JSON or XML API response: pretty-print, validate, and explore a collapsible tree view.
  • OpenAPI / Swagger Viewer — Paste OpenAPI in YAML or JSON and browse interactive docs—paths, schemas, and examples in one place.
  • Webhook Payload Tester — Practice webhook debugging client-side: log sample POST bodies locally (e.g. localStorage) when a public capture URL is not available.
  • HTTP Status Code Reference — Search HTTP status codes with plain-English meanings, typical causes, and what to do next.
  • MIME Type Lookup — Map filenames or extensions to MIME types for Content-Type headers, uploads, and API contracts.
  • API Rate Limit Calculator — Given X requests per minute and a daily budget of Y calls, see pacing and when you hit the wall.

Frequently asked questions

What does the OAuth 2.0 Flow Visualizer do?
It helps you learn and debug the authorization code flow: you enter your authorization and token endpoint URLs, client id, redirect URI, and scopes, then the tool builds the authorize URL, explains the redirect back with an authorization code, and formats the token exchange (including optional PKCE). Everything runs in your browser—no tokens are sent to this site’s servers.
Does this tool perform real OAuth requests?
No. It only composes URLs and form bodies so you can copy them into your own app, curl, or API client (for example the HTTP Request Builder in this catalog). Your authorization server receives requests only from tools you run yourself.
What is PKCE and when should I use it?
PKCE (Proof Key for Code Exchange, RFC 7636) adds a code_verifier and code_challenge so that intercepted authorization codes cannot be exchanged without the original verifier. Public clients—mobile apps and single-page apps without a confidential backend—should use PKCE. Confidential server-side clients often still use PKCE as defense in depth.
Why is the state parameter required?
The state value should be unpredictable and tied to the user’s session. After redirect, your app compares the returned state to the stored value to mitigate cross-site request forgery on the redirect. This tool reminds you to set state; generate a new random value per login attempt.
Can I use this for OpenID Connect?
Yes. OIDC builds on OAuth 2.0: use scope values like openid profile email, request response_type=code, and after token exchange you typically receive an id_token alongside access_token. Decode ID tokens locally with the site’s JWT decoder for inspection only—always validate signatures and claims on the server.
Why might token exchange fail with invalid_grant?
Common causes: authorization code already used or expired, redirect_uri mismatch between authorize and token steps, wrong client_id, clock skew, or PKCE code_verifier not matching the original code_challenge. Compare exact redirect URIs (including trailing slashes) with your app registration.
Is it safe to paste production client secrets here?
Avoid pasting live secrets into any third-party web page. Prefer staging credentials, redacted examples, or run this tool offline in your own fork. The client secret field is for composing curl examples; it is not uploaded by this page.
Which related tools should I use next?
Use the URL encoder for tricky redirect URIs, the JWT decoder to inspect OIDC id_tokens after exchange, the JSON formatter for token responses, and the API Developer Toolbox’s HTTP Request Builder to POST to the token endpoint—links are on this page and in the home catalog.