The three token types
- access_token — proves the bearer can call the API. Short-lived (5–60 min typical). Sent in
Authorization: Bearer …header. - refresh_token — exchanged for a new access_token when the current one expires, without re-prompting the user. Long-lived (days to months). Stored server-side.
- id_token — OpenID Connect addition. A JWT containing claims about the user (sub, email, name). The client decodes it and trusts the signed claims; doesn't send it back to APIs.
Sizes & formats
Real providers use opaque tokens (random bytes encoded as Base64-URL) or signed JWTs. This generator produces opaque format by default — ≈48 bytes / 256 bits of entropy, more than enough. The id_token (when enabled) is a real JWT with random claims signed by an HMAC for testing.
Use cases
- Seeding integration tests — paste tokens into your fixture data.
- Postman / Insomnia collections — use as placeholder Bearer tokens during dev.
- Auth0 / Cognito / Keycloak pre-deployment testing — generate once, point your client at a stub server returning these.
What this is NOT
These tokens are random — they will not authenticate against a real provider. To get real tokens, you need to complete an actual authorization flow (auth code, PKCE, client credentials etc.) against the provider's /token endpoint with your client credentials.