Mock Authentication Response

Runs in browser Mocking

Produce realistic auth responses (OAuth 2.0 token response, session login, OIDC id_token with a decodable unsigned JWT) plus failure variants for expired, invalid and locked accounts.

TEST DATA ONLY — all generated names, contacts, identifiers and numbers are synthetic and do not belong to real people or accounts.
Privacy: This tool runs entirely in your browser. Your input never leaves your device.

How does API authentication with tokens work?

Most APIs authenticate each request with a credential sent in a header: a bearer token (often a JWT issued by an OAuth 2.0 flow), an API key, or Basic credentials over TLS. The server validates it on every call — signature, expiry, audience, scopes — and answers 401 when it is missing or invalid and 403 when it is valid but not allowed. Testing authentication means trying each of those paths, not only the happy one.

Security note: Broken authentication and broken object-level authorization top the OWASP API Security list. Test that an expired, tampered or other-user token is refused, and that every object id is checked against the caller — not only the endpoint.

Read the guide: What is a JWT? JSON Web Tokens Explained

How to use Mock Authentication Response

  1. Optionally enter the user email, scopes and roles.
  2. Pick the shape and the outcome (success or a failure case).
  3. Generate and use the body in front-end auth mocks.

Mock Authentication Response features

  • OAuth 2.0, OpenID Connect, JWT pair, session cookie and API key shapes
  • Decodable unsigned JWTs (alg "none") or mock HS256 signatures with realistic claims
  • Failure variants: invalid credentials, expired token, locked account, unverified email, MFA required
  • Correct headers: Cache-Control: no-store, WWW-Authenticate, Set-Cookie, Retry-After
  • Decoded claims shown alongside the response

Mock Authentication Response example

OAuth 2.0 token response

Input:

Shape: OAuth 2.0, outcome: success, expires in 3600

Output:

{
  "access_token": "eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiI…",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "rt_9kM2…",
  "scope": "openid profile email offline_access"
}

Frequently asked questions about Mock Authentication Response

What shapes are generated?

OAuth 2.0 token responses, OpenID Connect responses with an id_token, JWT access/refresh pairs with a user object, session logins with a Set-Cookie header and CSRF token, and API key issuance.

Are the JWTs real?

They decode with any JWT tool and contain realistic claims (iss, sub, aud, iat, exp, scope, roles), but they are unsecured (alg "none") or carry a random mock signature. No server must ever accept them.

Which failure cases exist?

Invalid credentials/grant, expired token (401 with WWW-Authenticate), locked account (423 with Retry-After), unverified email (403) and MFA required.

Can I set the user and scopes?

Yes — provide the email, scopes and roles; the name is synthetic. The decoded claims are shown next to the response for quick inspection.

Technical notes

The access and id tokens are built as header.payload. with an empty signature, which RFC 7519 defines as an unsecured JWT, or with a random signature segment when a mock HS256 header is requested. They carry iss, sub, aud, iat, exp, nbf, jti, scope and roles so client-side expiry logic can be exercised, but they cannot be verified by any real server.

References