stuntstunt
← all adapters

auth0-style

simulates Auth0 Authentication & Management API v2

restadapter v0.1.017 routes

verification

VMVM tier — no SDK suite yet· surface 17 · not implemented 3 · differs 4

use it

# add to stunt.yaml
services:
  auth0:
    adapter: embedded:auth0-style

# then
$ stunt up

The embedded: source extracts this adapter from the binary — no git clone, fully offline.

how to mock the Auth0 Authentication & Management API locally

Install stunt, paste the service block above into stunt.yaml, run stunt up — then point your client at localhost instead of Auth0 Authentication & Management API. It works offline, keeps state across requests and restarts, and every response is synthetic: the route shapes, status codes, pagination, and webhook delivery follow the real Auth0 Authentication & Management API v2 surface — the data is fake, the behavior is real.

backing stores

usersrolesoauth_codesrefresh_tokens

api surface (17)

generated from the adapter manifest — exactly what boots, nothing more · covers 2% of the real API's 469 routes (derived from spec Auth0 Management API OAS @ 2.0)

17 routes
GET/.well-known/openid-configuration
GET/.well-known/jwks.json
GET/authorize
POST/oauth/token
GET/userinfo
POST/oauth/revoke
POST/dbconnections/signup
GET/api/v2/users
POST/api/v2/users
GET/api/v2/roles
POST/api/v2/roles
GET/api/v2/users/{id}
PATCH/api/v2/users/{id}
DELETE/api/v2/users/{id}
GET/api/v2/users/{id}/roles
POST/api/v2/users/{id}/roles
DELETE/api/v2/users/{id}/roles

VM-verified behaviors (26)

  • ✓discovery and JWKS are self-consistent for the host
  • ✓authorize issues a code; the grant mints a real RS256 token pair
  • ✓userinfo resolves the token to the seeded user; login_hint picks another
  • ✓spent and mismatched-redirect codes answer invalid_grant
  • ✓authorization codes expire after five minutes
  • ✓zero-based pages cover every user exactly once with true totals
  • ✓control characters in claims round-trip as escaped JSON
  • ✓a control-char audience survives the adapter's own token check
  • ✓patching onto another user's email is a 409 Conflict envelope
  • ✓fresh and self-owned email patches both succeed
  • ✓bad clients, redirect_uris, response types, and login hints get OAuth error redirects
  • ✓a missing redirect_uri is a 400, not a redirect
  • ✓the refresh grant returns fresh tokens without rotation
  • ✓revoke is idempotent and actually kills the token
  • ✓the access token dies at its 1-hour exp on both APIs
  • ✓the refresh token outlives it, then dies at 30 days
  • ✓client_credentials mints a bare JWS that drives the Management API
  • ✓the M2M token cannot call userinfo; a bad secret is invalid_client
  • ✓list returns the seeded users without leaking password internals
  • ✓q search and zero-based paging narrow the list
  • ✓create/get/patch round-trip the user and its metadata
  • ✓validation errors and delete leave the documented envelopes
  • ✓role create/list round-trip with conflict and name validation
  • ✓assignment is additive, idempotent, and validated
  • ✓signup creates an unverified user the Management API can see
  • ✓duplicate, weak, and unknown-client signups are rejected

Not implemented (3)

  • No MFA, Organizations, actions/hooks/flows, or email delivery
  • No user blocking or password change endpoints
  • No from/take checkpoint paging (page/per_page only)

Differs from the real API (4)

  • No hosted login or consent screen — /authorize auto-authenticates login_hint or first user
  • OAuth errors still 302 to unvalidated redirect_uri (RFC 6749 would refuse)
  • q is exact-match or substring only (no Lucene)
  • No scope enforcement — any valid RS256 token may call /api/v2/*
full scorecard →
want more of the Auth0 Authentication & Management API surface? adapters are YAML + Starlark — the authoring guide covers adding routes, fixtures, and state machines. Open an issue for anything big first, or just file a PR — merged routes ship in the next release.