JWT (JSON Web Token)

A JSON Web Token carries claims in a compact format. This playground uses a signed JWT in JWS compact form: three base64url-encoded segments for the header, payload and signature. JWT can also use JWE encryption, so not every JWT is a readable three-part token.

How it works

Send the token as a bearer credential. A verifier must restrict allowed algorithms, verify the signature with a trusted key, and validate the issuer, audience and time claims required by its application. The payload is not trustworthy merely because it can be decoded.

The misconception

Signing does not encrypt a JWS payload; anyone holding this playground token can read it. JWT also supports encryption through JWE. A self-contained token is not automatically revoked: immediate revocation needs additional controls such as a denylist, token version checks or introspection.

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.

Sources

Other terms

Bearer token — A credential where possession alone grants access — whoever holds it can use it.
JWKS — A JSON Web Key Set — the public keys an issuer publishes so that anyone can verify the tokens it signs.
Refresh token — A long-lived credential used only to obtain new short-lived access tokens, without asking the user to log in again.
OAuth 2.0 — The standard framework for letting an application get a limited access token, instead of handling the user's password.
PKCE — Proof Key for Code Exchange — a one-time secret that stops a stolen OAuth authorization code from being redeemed by anyone else.
OpenID Connect — An identity layer on top of OAuth 2.0 that tells the client who the user is, in a signed ID token.

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

Last updated 16 October 2026