JWT

JWT (JSON Web Token, pronounced “jot”) is a token format defined in RFC 7519 for transmitting signed claims between parties. A JWT is three base64url-encoded segments separated by dots: header.payload.signature.

The header declares the signing algorithm (HS256, RS256, ES256, etc.). The payload is a JSON object of claims — sub (subject), iss (issuer), exp (expiry), iat (issued at), plus any application-specific fields. The signature is computed over base64url(header) + "." + base64url(payload) using the algorithm and key declared in the header.

JWTs are used for stateless authentication (the server doesn’t need to store sessions; it verifies the signature on each request), inter-service authorization (OAuth 2.0 bearer tokens, OpenID Connect ID tokens), and short-lived URLs that encode access claims.

Common pitfalls: trusting alg: none, accepting symmetric-keyed tokens where asymmetric was expected, not validating exp. The JWT decoder inspects a token’s contents — it doesn’t verify the signature, because verification requires the issuer’s key.

Worked example

Decode the JWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSIsImlhdCI6MTcxNjQwMDAwMCwiZXhwIjoxNzE2NDg2NDAwfQ.signature. Header: {"alg":"HS256","typ":"JWT"}. Payload: {"sub":"12345","name":"Alice","iat":1716400000,"exp":1716486400}. The token was issued at Unix time 1716400000 (a moment in May 2024) and expires 86,400 seconds later — exactly 24 hours. A verifier receiving this token must: (1) recompute HMAC-SHA256 of header.payload with the shared secret and check it matches the signature; (2) check exp against the current time and reject if expired; (3) optionally check iss (issuer) and aud (audience) match expected values. Anyone — including the user’s browser, any intermediate proxy, or an attacker who steals the token — can base64-decode the payload and see Alice’s name and user ID. The token is signed, not encrypted.

When and why it matters

JWT matters whenever stateless authentication is the design choice — typical for SPAs talking to REST APIs, mobile apps with backend services, OAuth 2.0 / OpenID Connect federations, and microservice-to-microservice authorisation. The mistakes to avoid: (1) putting PII or sensitive data in the payload (it’s readable to anyone who has the token); (2) using long expiry times without a revocation strategy (24h+ tokens are dangerous if stolen); (3) accepting alg: none or letting the token pick the algorithm; (4) storing JWTs in localStorage where XSS can steal them — prefer httpOnly cookies with SameSite=Lax; (5) not validating aud, accepting tokens issued for sibling services. The pattern that works well: 5-15 minute access tokens + revocable long-lived refresh tokens + opaque server-side session for genuinely sensitive operations. Reference: RFC 8725 — JSON Web Token Best Current Practices.

Why JWTs are not encrypted by default: a vanilla JWT is signed but not confidential — anyone with the token can base64-decode the payload and read every claim, including the user’s email, roles, and any application-specific data the issuer chose to embed. This catches engineers out repeatedly: putting PII or internal user IDs in a JWT and assuming the token is a black box is a data leak waiting to happen. For confidentiality, encrypt the payload using JWE (JSON Web Encryption, RFC 7516), which produces a five-segment token with proper encryption alongside the signature. Most production systems either keep PII out of the payload or use opaque session tokens with server-side state lookups instead.

Refresh tokens, expiry, and the revocation problem: stateless verification is JWT’s headline feature and also its biggest operational liability — once issued, a JWT cannot be revoked until it expires. The standard mitigation is short-lived access tokens (5-15 minutes) paired with long-lived refresh tokens (days to months) that are revocable via a server-side denylist; the client trades the refresh token for a fresh access token periodically. Long-lived JWTs (24-hour and up) are an anti-pattern for anything sensitive — a stolen token is a free pass until expiry. Convertitive’s JWT decoder highlights the exp claim so you can quickly see whether a token is over-lived. Reference: RFC 7519 — JSON Web Token.