This mints real, correctly-signed JWTs — for tests, fixtures, and local development against an API that expects bearer tokens. It is not an authorisation server, and it should never produce a credential your production system trusts.
What gets produced
A complete access token with the claims a well-behaved resource server checks: iss, sub, aud, iat, nbf, exp, scope and a random jti. Alongside it, the JSON response an OAuth token endpoint would return, so you can stub the endpoint as well as the token.
Access tokens and refresh tokens are different things
The refresh token option deliberately emits an opaque random string rather than a JWT, because that is the correct design.
An access token is short-lived and self-describing. Your API validates it locally and never calls the issuer, which is the entire performance argument for JWTs.
A refresh token is long-lived and must be revocable. That means the issuer looks it up in a database on every use — so there is nothing to gain from making it self-describing, and a great deal to lose: a long-lived JWT that cannot be revoked is the worst of both models.
Audience is the claim people forget
aud names the API the token was minted for. If your resource server does not check it, it will accept any token from the same issuer — including one issued to a different, less trusted service. In a multi-service estate sharing an identity provider, an unchecked audience means every service can impersonate every other.
Secret length matters for HS256
HMAC-SHA256 with a short secret is brute-forceable offline: an attacker with one token can search for the key that verifies it. Use at least 32 random bytes — the secret generator at 256 bits produces exactly that. The strength readout on this page measures what you actually supplied.
Why production uses RS256
HS256 is symmetric: every service that verifies a token also holds the key that mints them. One compromised service can forge tokens for all of them.
RS256 and ES256 split this: the issuer signs with a private key, and every resource server verifies with a public key that cannot forge. That is why real authorisation servers publish a JWKS endpoint. Asymmetric signing is not offered here precisely because generating a production signing key in a browser page would be the wrong thing to encourage.
Frequently asked questions
Can I use these tokens in production?
No. The secret was typed into a web page and the tokens are minted client-side with no authorisation logic behind them. Use a real authorisation server.
How do I test that my API rejects an expired token?
Set the lifetime to its minimum, wait, and send it. Or paste a token into the JWT decoder to confirm what your validator should be seeing. Testing the rejection path matters as much as testing the success path.
What scopes should I include?
Only the ones the endpoint under test requires. Testing with an over-scoped token means you never discover that your authorisation checks do not work — a common and quiet failure.
Why is jti included by default?
It gives each token a unique identifier, which makes replay detection and emergency denylisting possible. It costs 22 characters and is worth having from the start.