Mock OAuth for MVPs and tests
dummyauthProvider-shaped mock OAuth and OIDC server for development and testing
Mock the OAuth providers you will ship against. Same env variable names as production; swap issuer URL and client credentials when you go live.
Sign in and create a project at https://dummyoauth.com/p/your-project. Add a provider preset, register localhost or CI redirect URLs, and add dummy users for consent screens.
On Integration, copy ready-to-paste env vars so names match what you use in production. When you go live, change the issuer URL and client id and secret.
- Same env vars as prod
- Swap issuer when live
- Hosted team sandbox
- GitHub
- Microsoft
- Cognito
- Generic OIDC
Create a project issuer in minutes. Development and test only.
How we compare
Honest notes for dev and test workflows. dummyÔauth is not a production identity platform.
- How is dummyÔauth different from a generic OIDC mock server?
- Generic mocks expose one issuer with standard /authorize and /token paths. dummyÔauth emulates Google, GitHub, Microsoft, Cognito, and more with the same URL shapes and response patterns your SDK expects in production, so you change fewer lines when you swap to a real provider.
- Why not use oauth2-mock-server in my test suite?
- oauth2-mock-server is excellent for programmatic unit tests inside Node. dummyÔauth is for full browser redirects, a dashboard, dummy users, and team-shared hosted issuers at dummyoauth.com/p/your-project without bootstrapping a server in every test file.
- Do I need Keycloak or another real IdP for local OAuth?
- Keycloak gives you production-grade semantics but heavy setup. dummyÔauth is a development and test mock only: create a project, copy Integration env vars, and run MVP login flows in minutes. Plan a staging run on the real provider before launch.
- Can I use dummyÔauth in production?
- No. It is a mock identity provider for development, automated tests, and early MVPs. Use Google, GitHub, Auth0, WorkOS, or another production IdP when you ship.
- Are tokens stable for long CI jobs?
- Authorization codes and access tokens are kept in memory and expire after about ten minutes. For typical E2E runs that is enough; split very long suites or re-auth between jobs. See the OAuth testing in CI guide for patterns.
Use cases
For anyone who needs realistic login flows without provisioning real Google, GitHub, or similar projects for every machine and pipeline.
App developers
Exercise the same login path you ship against the preset that matches production, without creating OAuth apps in every vendor dashboard.
Teams and shared dev setups
Share one project slug and the same Integration copy so local setup stops drifting into "works on my machine."
CI and end-to-end tests
Point automation at your hosted project issuer. Use redirect URLs that fit your runner, including wildcards when ports change every run.
Library and SDK authors
Hit each vendor's metadata and key URLs through one hosted stand-in instead of hand-maintaining mocks per provider.
Demos and workshops
Walk through real redirects and consent without provisioning cloud identity projects for the room.
Multi-provider and migration prep
Keep the environment variable names your framework expects. Point at dummyÔauth until you go live, then swap the URL and client id and secret.
How it works
Three steps from sign-in to a working login loop with your hosted project issuer.
Account
Sign in with GitHub, then create projects and add provider presets.
Project and providers
Each project gets its own URL. Add one or more presets per project.
Clients and dummy users
Register redirect URLs, add dummy personas, then copy env snippets and endpoints from Integration into your app.
Ready to try it?
Sign in with GitHub and create a project in minutes.
Development and test only
Built for development, MVPs, and automated tests. Not a production identity provider. Do not use dummyoauth for real user authentication.