b2KIT

OAuth 2.0 Playground

Interactive OAuth 2.0 flow simulator for learning authorization code, implicit, and client credentials grants.

Tested tool guide Tested browser tools Checked August 16, 2026

What OAuth 2.0 Playground does and how it behaves

This playground simulates the three standard OAuth 2.0 grants - authorization code, implicit, and client credentials - and walks you through each one request by request. You supply client parameters, and the page shows the redirect to the authorization server, the code (or token) that comes back, and the token exchange, step by step, with what the client sends and what the server returns. Everything runs in the browser; no real provider is contacted. The step beginners consistently misread: the code in the redirect URL is not the access token. It must be exchanged at the token endpoint before any token exists, and it can be redeemed only once.

How the result is produced

1

Guided walk-through of one grant

You choose authorization code, implicit, or client credentials, fill in client parameters, and the playground advances through the steps that flow requires: the authorization request, the redirect to the simulated authorization server where approval is granted, the redirect back carrying the code, and the token request. Each step shows the request and its response side by side.

2

Simulated endpoints, standard formats

The authorization and token endpoints are simulated inside the page, so no request leaves the browser and no real credentials are involved. The messages use the formats real servers use: query parameters on the authorize request, a form-encoded token request with grant_type=authorization_code, and a JSON token response carrying access_token, token_type, expires_in, and scope.

Good uses

  • You are about to write your first OAuth integration and want to see where the code, the state parameter, and the token each appear before touching a real provider's endpoints.
  • You need to choose between grants: run the same client and scope through all three and compare how the token arrives in each - in a JSON response, in the redirect URL fragment, or directly when the client authenticates itself.
  • You are building a client library or script and want a reference for the exact token request: parameter names such as grant_type, code, redirect_uri, client_id, and client_secret, and the shape of the JSON response.

Limits and checks

  • The simulation is a model, not a provider: real authorization servers commonly add requirements the playground does not enforce, such as PKCE, exact redirect URI matching, and nonces, so a flow that succeeds here can fail against a live endpoint on the first try.
  • Every code and token it displays is generated for the session and works nowhere else. Do not replay them against a real API, and do not take their expiry values as representative of any specific provider.
  • The implicit grant it demonstrates puts the access token in the redirect URL fragment, where it is visible in browser history. Current best practice recommends the authorization code grant with PKCE instead, so treat the implicit variant as something to understand, not a pattern to copy.

Common questions

Can I paste my real client ID and secret here and get a live token?

No. The playground simulates its own authorization server inside the browser, so nothing is sent to Google, GitHub, or any other provider, and no token it returns will authenticate anything outside the page. Use it to learn the shape of each flow, then repeat the same steps against the real provider's documented endpoints with the provider's own credentials.

Why does the authorization code grant need two round trips when client credentials returns a token in one?

Because the two grants answer different questions. In the code grant, the redirect carries the user to the authorization server, the user approves, and the code proves that approval when the client exchanges it with its secret; the round trips are how the user's consent is transmitted. Client credentials authorize the client itself, usually for server-to-server calls, so no user step and no redirect exist.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools