What is a JSON Web Token (JWT)?

A JSON Web Token is a compact, URL-safe token that carries signed JSON claims, letting servers verify requests without stored sessions. That is RFC 7519’s own framing — “a compact, URL-safe means of representing claims to be transferred between two parties” — and the two ideas in it carry everything that follows: the token contains its facts, and a signature makes those facts checkable by anyone holding the right key, with no database in the loop.

Key takeaways

A JWT, decoded

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJzdWIiOiJ1c3ItOGZrMiIsInJvbGUi… . dBjftJeZ4CVP…

header     { "alg": "HS256", "typ": "JWT" }
payload    { "sub": "usr-8fk2",  "role": "editor",
             "iss": "https://api.example.com",  "aud": "example-web",
             "iat": 1767024900,  "exp": 1767025800 }        ← 15-minute life
signature  HMACSHA256( base64url(header) + "." + base64url(payload), secret )

Anyone can DECODE the first two parts — Base64Url is packaging, not encryption.
Only key-holders can FORGE the third — which is the entire trick.

The contrast worth seeing in code — the stateful alternative every JWT decision is measured against:

// JavaScript / Node.js — Back4app JS SDK
// The stateful contrast: Back4app issues revocable session tokens
const user = await Parse.User.logIn('ada', 'correct-horse-battery');
const token = user.getSessionToken(); // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
await Parse.User.logOut(); // token invalid NOW — no waiting for an exp claim

// Flutter / Dart — Back4app Flutter SDK
// The stateful contrast: Back4app issues revocable session tokens
final user = ParseUser('ada', 'correct-horse-battery', null);
await user.login();
final token = user.sessionToken; // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
await user.logout(); // token invalid NOW — no waiting for an exp claim

// iOS / Swift — Back4app Swift SDK
// The stateful contrast: Back4app issues revocable session tokens
let user = try await User.login(username: "ada", password: "correct-horse-battery")
let token = user.sessionToken // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
try await User.logout() // token invalid NOW — no waiting for an exp claim

// Android / Kotlin — Back4app Android SDK
// The stateful contrast: Back4app issues revocable session tokens
val user = ParseUser.logIn("ada", "correct-horse-battery")
val token = user.sessionToken // r:abc123… — opaque, server-side state
// Every request presents it; the server can revoke it instantly:
ParseUser.logOut() // token invalid NOW — no waiting for an exp claim

How verification works

Precision the explainers skip: “JWT” names the claims format; what everyone actually passes around is a JWS (RFC 7515) — the signed serialization — while JWE is the encrypted sibling for payloads that must stay unreadable. And verification is two jobs, not one: check the signature, then validate the claims — exp and nbf against the clock, iss against your allowlist of issuers, aud against this service’s identifier. A perfectly signed token that’s expired, from the wrong issuer, or minted for a different audience is a perfectly signed attack.

Claims: the payload’s vocabulary

Keep payloads lean twice over: tokens ride every request as headers (cookies cap near 4 KB, and each claim is repeated bandwidth), and everything in them is legible to whoever holds the token.

JWT vs. session tokens

The unfashionable truth several best-practice guides now lead with: for a server-rendered app with one backend, framework sessions are simpler and more controllable — JWTs earn their keep when tokens must be verified across services or by parties who shouldn’t phone home per request.

The revocation problem, honestly

Statelessness is the inability to revoke — the same property, described twice. A signed token is valid until exp no matter what happened since: logout, password change, account ban. Every fix reintroduces state, so choose which flavor: a denylist keyed on jti + iss (the OWASP-recommended construction) checked per request — small state, but state; key versioning, which revokes everyone at once; or the standard architecture — short-lived access tokens (5–15 minutes) plus revocable refresh tokens with rotation: each refresh issues a new refresh token and retires the old, so a stolen one dies on first replay, and reuse of a retired token flags theft and kills the whole token family. Revocation latency then equals the access token’s lifetime — which is the real reason those lifetimes are short.

Choosing an algorithm — and the attacks on the choice

The attack section RFC 8725 exists for, in three sentences. alg: "none" is a legal header value — libraries that honor it accept unsigned tokens. The confusion attack: a verifier that lets the token’s header pick the algorithm can be handed an “HS256” token signed with the server’s public RSA key as the HMAC secret — a public value used as a private one. Both die the same way: the verifier pins its accepted algorithms and keys in configuration and never trusts the header to choose.

Where to store JWTs in a browser

The threat model, not the folklore: localStorage trades CSRF-immunity for XSS-theft, cookies trade the reverse — which is why the consensus splits the pair: access token in memory, refresh token in a hardened cookie.

Common use cases

• API authentication — the bearer token behind Authorization headers on REST and GraphQL APIs.
• Microservice identity — one gateway-issued token verified independently by every service, no shared session store.
• OpenID Connect ID tokens — the signed identity assertion in every social login — always a JWT.
• Cross-system handoffs — signed links, webhook payloads, download grants: claims verified by a party that can’t call you back.
• Stateless authorization hints — roles and tenant IDs carried in claims, with the authoritative check still server-side.

Should you use JWTs or sessions? A decision matrix

Limitations and trade-offs

• Irrevocability is structural. Every mitigation — denylists, short lifetimes, rotation — is a partial return of the state you removed; price that in before choosing stateless.
• Claims go stale. Roles snapshot at issuance; a demoted admin stays an admin until expiry. Short lifetimes bound the staleness window.
• The payload is public. Treat it as readable by the user and any token thief — identifiers yes, secrets and PII no.
• Library defaults have burned people. Algorithm pinning, claim validation, and typ checking are your configuration responsibilities, not the library’s guarantees.
• Size compounds. Every claim rides every request; generous payloads tax mobile bandwidth and can overflow cookie limits.

Tokens on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. The platform’s own choice illustrates the decision matrix: client sessions use revocable, server-side session tokens — the code tabs above — so logout, password changes, and dashboard-side session termination take effect immediately, with no expiry window to wait out. JWTs appear where they belong: identity providers’ OIDC ID tokens are verified server-side by auth adapters during social login, and Cloud Code functions can mint or verify JWTs for third-party handoffs using standard libraries — with the signing secret in server-side configuration, never shipped to clients. Stateful where control matters, stateless at the edges where verification must travel: the architecture this article argues for, preassembled.