Guide
How dummyÔauth works
Run OAuth and OpenID Connect against emulated issuers on your machine. Same env var names as production, different issuer URL and client credentials until you are ready to go live.
Overview
dummyÔauth gives each project its own issuer base path (for example /p/your-slug). You add providers that mimic Google, GitHub, generic OIDC, and more. You register OAuth clients with redirect URIs and copy env snippets into your app. Dummy users are personas you use when exercising login and consent without touching a real IdP.
Building blocks
Project
Names your sandbox and defines the issuer URL segment. Everything below (providers, users, clients) is scoped to that project.
Provider preset
Shapes discovery documents and token behavior so your app sees the same patterns it will see against Google, GitHub, Microsoft, Cognito, or plain OIDC.
Dummy users
Personas for login and consent screens. They are shared across the project so you can test multiple accounts without creating real IdP users.
OAuth clients
Client ID, client secret, and redirect URIs your app registers. Copy the generated env snippet and wire your SDK or framework as usual.
End-to-end workflow
Typical path from empty workspace to a token in your app:
Sign in and open Projects
Authenticate with GitHub, then create a project. You will get a slug and issuer URL for that sandbox.
Attach provider presets
In Providers, choose presets that match what you will use in production so discovery and endpoints line up.
Add dummy users
Under Dummy users, create the personas you want to see on the consent screen.
Register a client and redirects
In OAuth clients, add redirect URIs that match your local app (for example http://localhost:3000/callback).
Integrate using the Integration page
Use Integration to copy issuer URL, endpoints, and env snippets into your codebase, then run the authorization code flow against dummyÔauth.
Dashboard areas
After you select a project, the sidebar focuses on tasks. Quick map:
- Projects
- Create and switch sandboxes; each has its own issuer path.
- Integration
- Central place for issuer URL, metadata, and copy-paste env for your app.
- Providers
- Configure emulated IdP behavior and presets.
- Dummy users and OAuth clients
- Personas for login flows and registered applications.
Production swap
Keep the same environment variable names your framework expects (for example OIDC_ISSUER, client ID, client secret). For local testing, values point at dummyÔauth. When you move to production, replace the issuer URL and credentials with your real provider from its console (Google Cloud, GitHub OAuth Apps, Entra, Cognito, and so on). Your application code stays the same; only configuration changes.
Not for public exposure
dummyÔauth is for development and automated tests. Do not expose it to the public internet without hardening. It is not a production identity provider.
FAQ
Do I need real Google or GitHub apps to use this?
No. dummyÔauth emulates those shapes locally. You only create real provider apps when you cut over.
Can I use multiple providers in one project?
Yes. Add the presets you need; pick the right issuer and client when you configure your app.
Where is consent handled?
Authorization requests for your project slug go through dummyÔauth's consent UI so you can test the full redirect flow.
Need help?
Join the DummyOAuth Discord community for setup questions and feedback.
Next step
Sign in, create a project, and open Integration to copy your first env snippet.