About OAuth 2.0 Playground
- Higher rate limits on backend-routed requests
- Persisted configs
About me
I am Michael Mineev, a senior software engineer. Much of my work involves designing authentication systems and integrating identity providers. I built this playground because I needed a flexible tool. If you are working on OAuth 2.0 or OpenID Connect and want to talk, you can find me on LinkedIn or use the feedback form.
Why I built this tool
One of the most common problems I kept running into was demonstrating authentication flows, testing them, and helping other developers integrate with these systems. In practice, that usually meant keeping raw authorization links in documentation, building custom clients again and again in different projects, using JWT inspection sites, or reaching for tools like Postman.
What problem it solves
I wanted a tool that I could reuse safely across many projects without creating new security concerns, while still making each step of the OAuth flow visible. That is how this app came about: an OAuth 2.0 client that helps you see what is happening under the hood while testing real authentication systems.
How it works
You provide your OAuth endpoints, client details, and optional scope values in the browser UI. The playground runs as an OAuth 2.0 client in your browser, sends the user through the provider authorization step, receives the returned code on the configured redirect URI, and performs the token exchange locally in the browser.
Security boundaries
This is a debugging tool, not a production client runtime. By default, OAuth configuration, client secrets, private keys, and tokens are stored locally in your browser and are not sent to our server. Three optional features deliberately cross that line: publishing a public key to the server-hosted JWKS endpoint (private keys are never uploaded for this); routing a PAR or introspection request through the backend proxy, which then sees whatever that request contains; and, if you sign in, syncing a saved configuration, which uploads its full contents — client secret and private keys included — to be stored encrypted at rest. The Privacy Policy and Terms spell out each case.
Client secrets are intentionally excluded from share links. The goal is to make the tool reusable across projects without turning it into a place where sensitive credentials are casually passed around.
Because token requests happen in the browser, your authorization server must explicitly allow the site origin through CORS for token exchange to succeed. That requirement is intentional: it makes usage transparent to authentication-system administrators and prevents the tool from being silently used against production systems that have not chosen to permit it.
When to use it
Use the playground when you need to confirm endpoint configuration, test PKCE behavior, inspect token responses, reproduce refresh token issues, or demonstrate OAuth behavior during development and support work.
The playground has been validated against Keycloak, WSO2 Identity Server, Auth0, Google, and FIWARE Keyrock OAuth 2.0 flows.
It also works well together with Playwright when you need repeatable browser-based authentication flows in automated testing.