JWT

JWT (JSON Web Token, pronounced "jot") encodes claims - pieces of information about a user or session - into a compact string that can be verified without a database lookup. The format is three Base64url-encoded segments separated by dots: header.payload.signature.

The server signs the token with a secret or private key. Any party with the correct key can verify the signature and confirm the token has not been tampered with. This makes JWTs well-suited for stateless authentication: no session storage required on the server.

Why it matters in Engineering: JWTs are the standard access token format in OAuth 2.0 flows, service-to-service auth, and identity propagation across microservices. The stateless convenience has a real cost: JWTs cannot be revoked before expiry unless you add a blocklist - which reintroduces state. Short expiry windows paired with refresh tokens are the standard mitigation.

Core Concepts

Header
Declares the token type (JWT) and the signing algorithm. Common choices: HS256 (HMAC) or RS256 (RSA).

Payload
Contains the claims: sub (subject/user ID), exp (expiry), iat (issued at), plus any custom claims your application needs.

Signature
The header and payload are signed using a secret (symmetric) or private key (asymmetric). A valid signature proves the token was not modified after issuance.

HS256 vs RS256
HS256 uses a shared secret - any party that can verify can also create tokens. RS256 uses a key pair - only the private key signs, any holder of the public key can verify. RS256 is the correct choice for multi-service architectures.

Expiry and Refresh
Keep access tokens short-lived (15 minutes to 1 hour). Use a refresh token to obtain a new access token without requiring the user to re-authenticate.