Are the tokens real JWTs?

No — access_token and refresh_token are fresh UUIDs, not signed JWTs. If your client decodes the access token and reads claims from it, this template will not satisfy it; pair it with the JWKS template and a real signed token instead.

Does it validate the grant or client credentials?

No. It never checks client_id, client_secret or the authorization code, and always returns the same successful response. To test the failure path, create a second mock returning a 400 with an OAuth2 error body.

How do I test token expiry and refresh?

Lower expires_in to a few seconds so your client's refresh logic fires quickly. Because each call returns a new refresh_token, you can also confirm your code stores the latest one rather than reusing the original.

Mock an OAuth2 token response

A POST mock that returns an RFC 6749-shaped token response with a fresh access_token and refresh_token.

This template returns an RFC 6749-shaped token response — access_token, token_type, expires_in, refresh_token and scope — with fresh token values on every call. It lets you build the client half of an OAuth2 flow before an identity provider is available, and test that your code stores, refreshes and expires tokens correctly.

Stands in for a third-party API endpoint.

Response payload

{
  "access_token": "{{faker.uuid}}",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "{{faker.uuid}}",
  "scope": "read write"
}

Fields worth knowing

Field	What it means
access_token	A fresh UUID on every call via {{faker.uuid}} — not a real signed token.
token_type	Hardcoded to Bearer.
expires_in	A hardcoded lifetime in seconds; edit it to test expiry handling.
refresh_token	A fresh UUID via {{faker.uuid}}.
scope	Space-separated scopes granted; edit it to test scope-gated logic.

Create the mock

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "POST",
  "response_status": 200,
  "content_type": "application/json",
  "response_body": "{\"access_token\":\"{{faker.uuid}}\",\"token_type\":\"Bearer\",\"expires_in\":3600,\"refresh_token\":\"{{faker.uuid}}\",\"scope\":\"read write\"}"
}'

Call it

curl -X POST https://quickmock.dev/m/<slug>

What you get

POST /m/<slug> -> 200 an RFC 6749-shaped token response
access_token/refresh_token are fresh UUIDs each call

How this differs from the real thing

access_token and refresh_token are just fresh UUIDs, not real signed JWTs, and the mock never checks client_id, client_secret, or an authorization code — it always returns the same successful response.

Sources

FAQ

Are the tokens real JWTs?: No — access_token and refresh_token are fresh UUIDs, not signed JWTs. If your client decodes the access token and reads claims from it, this template will not satisfy it; pair it with the JWKS template and a real signed token instead.
Does it validate the grant or client credentials?: No. It never checks client_id, client_secret or the authorization code, and always returns the same successful response. To test the failure path, create a second mock returning a 400 with an OAuth2 error body.
How do I test token expiry and refresh?: Lower expires_in to a few seconds so your client's refresh logic fires quickly. Because each call returns a new refresh_token, you can also confirm your code stores the latest one rather than reusing the original.

Ready to use it?

Open it in the mock builder to tweak first

Pairs well with this guide: Mock a REST API endpoint

Related templates

← All templates

Last updated: 2026-10-17