Skip to main content

OIDC Playground

Walk through the OpenID Connect authorization code flow with PKCE against Keycloak or any OIDC provider — one step at a time, entirely in your browser. See exactly what is sent, what comes back, and whether it checks out.

Runs entirely in your browser as a public client. Requests go only to the issuer you enter and the endpoints it advertises. Tokens stay in memory; only the in-flight state, nonce, and PKCE verifier are kept in this tab's session storage.
Flow: authorization code + PKCE (S256), public client.

1Issuer and discovery

For Keycloak: https://<host>/realms/<realm>. You can also paste the full /.well-known/openid-configuration URL.

2Client

Redirect URI (this page)
…
Space-separated. Keep openid to get an ID token.
No client secret field — on purpose. Anything shipped to a browser can be read by whoever runs it, so a browser app cannot hold a secret. Browser apps are public clients and prove possession with PKCE instead. Test confidential clients from a backend.
Configure your Keycloak client

In the admin console (Keycloak 26), open your realm → Clients → Create client, choose OpenID Connect, and give it a Client ID. Then:

Capability config
  • Client authentication: Off — this makes it a public client. Browser apps cannot keep a secret.
  • Standard flow checked (the authorization code flow). Implicit flow and Direct access grants can stay unchecked.
  • Require PKCE: On, with PKCE Method: S256 — Keycloak then rejects requests without a valid challenge. (Older Keycloak versions have this under Advanced → Proof Key for Code Exchange Code Challenge Method.)
Login settings
  • Valid redirect URIs: https://… — matched exactly, including the trailing slash.
  • Valid post logout redirect URIs: the same URI, or + to reuse the redirect URIs (needed for the logout step).
  • Web origins: https://… (or +) — so the browser may call the token and userinfo endpoints (CORS).

Use a test client in a non-production realm. Remove this site's URIs from the client when you are done.

3Authorization request

Fetch discovery and enter a client_id to build the URL.

4Token exchange

After you log in and return, the code is exchanged here automatically: a POST to the token endpoint with grant_type=authorization_code, the code, the redirect URI, and the PKCE code_verifier — no secret.

5Tokens

Decoded tokens appear here after the exchange.

6Userinfo, refresh, and logout

Available once you have tokens.

How the authorization code flow with PKCE works

  1. The client fetches the issuer's discovery document (/.well-known/openid-configuration) to learn its endpoints and keys.
  2. It generates a random state, nonce, and PKCE code_verifier, and sends the user to the authorization endpoint with the SHA-256 code_challenge.
  3. The user logs in. The server redirects back to the redirect_uri with a one-time code and the same state.
  4. The client checks state, then POSTs the code and the code_verifier to the token endpoint. The server hashes the verifier and compares it with the challenge before issuing tokens.
  5. The client validates the ID token — signature, iss, aud, exp, and nonce — before trusting who the user is.

This is the flow every browser app, mobile app, and server app should use. The implicit flow is deprecated; inspect an existing app's URLs with the Authorize URL Inspector or generate PKCE values with the PKCE Generator.

Testing a Keycloak client

The playground is a quick way to confirm a Keycloak client is set up correctly before you wire it into an app: redirect URIs, web origins, client scopes, protocol mappers, and the claims that end up in each token. Decode the tokens to check roles and mappers, then call userinfo to see what the server releases there. For deeper token analysis, paste any token into the JWT Decoder. For client setup, see the Keycloak overview.

Frequently asked questions

Is it safe to use this playground with a real identity provider?

The playground runs entirely in your browser. It talks only to the issuer you enter and the endpoints that issuer's discovery document advertises — never to Phase Two. Tokens are kept in memory and disappear when you leave the page; only the in-flight state, nonce, and PKCE verifier are stored in this tab's session storage so the flow survives the redirect. Use a dedicated test client, and remove this site's redirect URI when you are done.

Why can't I enter a client secret?

Because secrets don't belong in a browser. Anything delivered to a browser — including a value you paste into a form — can be read by whoever controls that browser, so single-page apps are public clients. Public clients prove they started the flow with PKCE instead of a secret. To test a confidential client, run the token exchange from a backend.

What do I need to configure in Keycloak?

Create an OpenID Connect client with Client authentication off (public), Standard flow on, this page's URL as a Valid redirect URI and Valid post logout redirect URI, and this site's origin (or +) in Web origins. Turn on Require PKCE with PKCE Method S256 (under Capability config in Keycloak 26) to make PKCE mandatory.

Why does the token exchange fail with a network or CORS error?

The browser calls the token endpoint directly, so the server must allow this site's origin. In Keycloak, add the origin (or +, meaning the same origins as the valid redirect URIs) to the client's Web origins. Other causes are an unreachable host, a TLS certificate your browser doesn't trust, or an http endpoint called from an https page.

What does the playground check in the ID token?

It verifies the signature against the issuer's JWKS, checks that the nonce matches the one sent in the authorize request, that iss is the discovery issuer, that aud contains your client_id (and azp when there are several audiences), that the token is not expired, and that at_hash matches the access token.

What is PKCE and why is it required?

Proof Key for Code Exchange (RFC 7636) binds the authorization code to the client that requested it. The client sends a hash of a random secret (the code_challenge) with the authorize request and the secret itself (the code_verifier) with the token request. An attacker who intercepts the code cannot redeem it without the verifier. OAuth 2.1 requires PKCE for every client using the code flow.