Testing OAuth 2.0, JWTs and token expiry

Most auth testing stops at "a valid token works, an invalid one does not", which leaves the interesting half untested: the token that was valid when the request started and expired before it finished. The APIs below issue genuinely signed, genuinely short-lived tokens, so refresh and expiry are things that actually happen.

OAuth and JWT testing — request and response sequence Sequence diagram for OAuth and JWT testing: POST /auth/v1/login answers 200 OK. POST /auth/v1/firebase-token answers 400 Bad Request. GET /auth/v1/me answers 401 Unauthorized. DELETE /webhooks/v1/subscriptions/{id} answers 403 Forbidden. Your client Fun API Playground POST /auth/v1/login 200 OK Token issued — use it as Authorization: Bearer <token> POST /auth/v1/firebase-token 400 Bad Request role must be "admin" or "viewer" GET /auth/v1/me 401 Unauthorized Missing or invalid token DELETE /webhooks/v1/subscriptions/{id} 403 Forbidden Viewer token not allowed
Real endpoints from the catalog — every request above is served, and every status code shown is one that endpoint actually returns.

How to practise it

  1. Complete the client-credentials flow and call a protected endpoint with the token you were issued.
  2. Wait for a short-lived token to expire and confirm your client refreshes transparently instead of failing the user's request.
  3. Exchange a refresh token, then attempt to reuse the old one and read the rejection.
  4. Run the authorization-code flow with PKCE, then retry with the wrong code_verifier.
  5. Drive the device-code flow end to end — the one that matters for CLIs and TVs, and the one nobody tests.
  6. Send a well-formed but wrongly-signed JWT and confirm it is refused as firmly as a missing one.

APIs to try it on

Status codes involved

Other techniques

Getting started guide · All 39 mock REST APIs

Last updated