JWT (JSON Web Token)

A JWT is three base64url-encoded segments separated by dots: a header naming the signing algorithm, a payload of claims, and a signature over the first two. Because the signature proves the payload has not been altered, the server can trust the claims inside it without storing any session state.

How it works

The client sends it as a bearer token. The server verifies the signature with the key, then reads the claims — `sub` for the subject, `exp` for expiry, `iat` for issue time, plus whatever roles or scopes the issuer chose to include. Expiry is enforced by the server checking `exp`, not by anything in the token stopping it from being sent.

The misconception

That a JWT is encrypted. It is signed, not encrypted: anybody holding the token can decode the payload and read every claim in it. Nothing secret belongs in a JWT. The second misconception is that a JWT can be revoked — a stateless token stays valid until it expires, which is why short lifetimes and refresh tokens exist.

Try it here

`POST /auth/v1/login` with admin/admin123 issues a genuinely signed JWT. Decode the middle segment and read your own claims; then wait for it to expire and watch the 401 arrive.

Related

• Testing OAuth 2.0, JWTs and token expiry
• What a bearer token is

Other terms

• Mock API — A stand-in for a real API that returns realistic responses without the real system behind it.
• REST API — An API that models a system as addressable resources, manipulated with standard HTTP methods.
• ETag — An opaque version identifier for a representation, used to avoid re-sending it and to detect conflicting writes.
• HATEOAS — Hypermedia as the Engine of Application State — responses carry the links to whatever you can do next.
• Bearer token — A credential where possession alone grants access — whoever holds it can use it.
• Webhook — An HTTP callback the server sends you when something happens, instead of you polling to ask.

All glossary terms · Testing techniques · All 39 mock REST APIs