About OAuth 2.0 Playground
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 entirely 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. OAuth configuration, client secrets, and tokens are stored locally in your browser and never sent to our server. The exception is client cryptographic keys: private keys stay in your browser, but public keys are published to a server-hosted JWKS endpoint so authorization servers can discover them.
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.