What is a JWT?
Also known as
JSON Web Token
A JSON Web Token (JWT, usually pronounced “jot”) is a standard for sharing signed authentication claims between web services. One service states some facts about a user — who they are, what they’re allowed to do, when the statement expires — signs them, and hands the result to another service, which can verify the signature without calling back.
What’s inside a JWT
A JWT is three base64url-encoded parts joined by dots: header.payload.signature.
- Header — a small JSON object naming the signing algorithm, e.g.
{"alg": "HS256", "typ": "JWT"}. - Payload — the claims, also JSON.
- Signature — the header and payload signed with a secret or private key.
The payload holds claims, which are just key/value pairs. Some are standardized:
{
"sub": "user_1042",
"iss": "https://auth.example.com",
"aud": "analytics.example.com",
"exp": 1753104000,
"iat": 1753100400,
"email": "ada@example.com",
"groups": ["finance"]
}
sub is the subject (who the token is about), iss the issuer, aud the intended audience, iat when it was issued, and exp when it stops being valid. Everything else is custom.
Signed, not secret
The most common misconception: a JWT is signed, not encrypted. Anyone holding the token can base64-decode the payload and read every claim. The signature only proves the payload wasn’t altered and came from someone holding the key. So never put anything in a JWT you wouldn’t be comfortable showing the bearer, and always send tokens over HTTPS.
Verification also has to be done properly. The receiving service must check the signature against the expected algorithm, reject tokens whose alg doesn’t match what it expects, and confirm exp, iss, and aud before trusting a single claim.
Expiry and revocation
Because verification is offline, a JWT stays valid until it expires — there’s no lookup that can cancel it mid-flight. That’s the trade-off for not needing a database round trip on every request. In practice teams keep the lifetime short (minutes to an hour) and issue a fresh token when needed, rather than trying to revoke tokens already in the wild. If you need instant revocation, a server-side session token is the better fit.
Where you’ll run into JWTs
JWTs are the workhorse of single sign-on: your identity provider authenticates the user, signs a token describing them, and the application trusts it. They’re also how signed embedding works — the parent application signs a token describing which content to show and which filters to apply, so the embedded view can’t be tampered with by whoever is looking at the page.
Related terms
Put it to work
- Okta — Integration
- Auth0 — Integration
- Security analytics — Overview