dummyauth

OAuth guides

Mock OAuth and OIDC for development and tests

Use a mock IdP for dev and CI: your app keeps localhost callbacks while discovery, consent, and tokens come from an issuer like dummyÔauth.

7 min read

A mock OAuth server is a development-only OpenID Connect provider you configure in a dashboard, not software you install beside your app. Your application runs on localhost or in CI; redirects go to your loopback callback while authorize, token, discovery, and JWKS requests go to the issuer (for example https://dummyoauth.com/p/your-project).

What "mock" means here

Unlike stubbing HTTP in unit tests, the flow is real OAuth/OIDC over the network: browser redirect, authorization code, token exchange, JWT validation against the provider's JWKS. Dummy users and consent screens replace real Google or GitHub accounts. The service is for dev and test only, not production identity.

Emulated provider presets shape discovery metadata and claims so your app sees Google-, GitHub-, Microsoft-, or generic OIDC-shaped tokens before you provision production credentials.

Two URLs to keep straight

  • Issuer URL — HTTPS host + project path on the mock IdP (where discovery and tokens live).
  • Redirect URI — where the user returns after consent, usually your app on http://localhost:3000/... or a CI loopback URL.

Register the localhost callback on an OAuth client in your project dashboard and paste the issuer into OAUTH_ISSUER(or your framework's equivalent).

MVPs and Google Cloud OAuth in Testing mode

Shipping social login before every vendor console is ready is a common MVP pattern. Google OAuth apps in Testing mode only allow listed test users; redirect URI mismatches block sign-in with vague errors. A provider-shaped mock (for example emulated Google paths on https://dummyoauth.com/p/your-project) lets you run the same SDK config and env var names while you wait for app review, then swap OAUTH_ISSUER and client credentials when the real OAuth client is live.

When a mock IdP helps

  • MVPs that need social-login-shaped flows before vendor OAuth apps are approved.
  • CI and Playwright suites that must not depend on live Google or GitHub rate limits.
  • Shared team sandboxes: one project, consistent dummy users, no per-engineer IdP admin access.
  • Preview deployments that register ephemeral redirect URIs on the same project.

When it is not enough

  • Production authentication (use a real IdP with its security and compliance posture).
  • Final validation of vendor-specific edge cases before launch.
  • Load tests at full IdP scale (use provider sandboxes or synthetic tokens instead).

Plan at least one staging run against the real provider before release.

Typical setup on dummyÔauth

  1. Create a project (defines the /p/your-slug issuer segment).
  2. Add a provider preset (Google-shaped, GitHub-shaped, OIDC, etc.).
  3. Register an OAuth client with your localhost or CI redirect URI.
  4. Add dummy users for consent and copy Integration env snippets into your app.

Redirect and env var details: local OAuth development. CI patterns: OAuth testing in CI.

Related guides