A WireMock simulation of Auth0's REST API — covering the hosted login page, authorization code exchange, OIDC discovery, and user info.
A shared instance of this template runs on a public endpoint — call it right now from curl, an SDK, or an AI agent. Responses are fixed examples and behavior can't be changed; rate limits apply.
Jump to the endpoints ↓Run this template as a mock API in WireMock Cloud for a private instance you control — edit stubs, add stateful scenarios, use dynamic response templating, and inspect requests in the log.
Open in WireMock Cloud (free) →Live sandbox · no signup, no API key
A running WireMock Cloud instance of this template, callable right now from a terminal, a script, or an AI agent.
Endpoints
GET OpenID Configuration
curl -s -X GET 'https://q4wrz.wiremockapi.cloud/.well-known/openid-configuration'GET CSS
curl -s -X GET 'https://q4wrz.wiremockapi.cloud/css/stylesheet.css'GET Landing page
curl -s -X GET 'https://q4wrz.wiremockapi.cloud/'Spec catalog — Auth0 Mock API (2.0.0) · 10 endpoints
| Method | Path | Summary |
|---|---|---|
| GET | / | Landing Page |
| GET | /.well-known/jwks.json | JSON Web Key Set |
| GET | /.well-known/openid-configuration | OpenID Connect Discovery |
| GET | /authorize | Authorization Endpoint |
| GET | /css/{cssId} | Get css by cssId. |
| GET | /favicon.png | Get favicon.png. |
| POST | /login | Login Form Handler |
| POST | /oauth/token | Token Endpoint |
| GET | /userinfo | UserInfo Endpoint |
| GET | /v2/logout | Logout Endpoint |
Unauthenticated WireMock Cloud demo sandbox for Auth0 — not an official Auth0 sandbox, and it returns simulated example data only.
Where most auth mocks stop at JSON endpoints, this one includes the front of the flow too: /authorize serves an actual styled sign-in page whose form posts back and redirects to your callback with an authorization code. Exchange that code at /oauth/token and the stub returns a bearer access token alongside an RS256-signed id_token whose issuer is the mock itself — verifiable against the JWKS document the template publishes.
Auth0's SDKs identify a tenant by bare domain, and that's the whole override surface needed — give auth0-spa-js the sandbox host as its domain and the login redirect, code exchange, and user lookup all route to the mock:
Server-side it's the same trick: any OIDC client library configured by issuer URL can point at the sandbox origin, pull the discovery document, and run the code flow against it. Swap in your own WireMock Cloud copy's URL when you need to control the claims that come back.
It makes the authentication path testable end to end without a tenant: onboarding flows in E2E suites click through a real login screen, token-handling middleware sees authentic JWT structure, and none of it depends on Auth0 rate limits or a test user directory.
import { createAuth0Client } from "@auth0/auth0-spa-js";
// the mock stands in for your-tenant.auth0.com;
// clientId can be anything — it is never verified
const auth0 = await createAuth0Client({
domain: "q4wrz.wiremockapi.cloud",
clientId: "any-value",
authorizationParams: {
redirect_uri: window.location.origin,
},
});
await auth0.loginWithRedirect();Any at all — the form handler doesn't maintain a user store, it just completes the redirect with a code. Type a made-up address and password and the flow proceeds. Never enter credentials you actually use anywhere, though, since this is a shared public mock.
Structurally yes: it's a genuine RS256 signature over standard OIDC claims, and the matching public key sits in the mock's JWKS endpoint. Point your validator's key resolution at the sandbox issuer and signature checks succeed; audience and expiry are fixed mock values, so relax those assertions accordingly.
That's the template's specialty — authorize renders the sign-in page, submitting the form redirects to whatever redirect_uri you supplied with a code attached, and the code exchanges at the token endpoint. E2E frameworks like Playwright can click through it exactly as a user would.
The prototype models the primary happy path only — one login form, one successful exchange. Divergent outcomes (a rejected password, an MFA challenge, an expired code) are stubs you'd add to a private copy in WireMock Cloud, where the login sequence's responses are yours to script.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.