JWT
Also known as: JSON Web Token, Bearer token, JWT token, JWKS, JWE
A JWT (JSON Web Token) is a small, self-contained package of information -- like a user's ID, role, and expiry time -- cryptographically signed so the recipient can verify it wasn't tampered with.
Used to authenticate API requests and pass identity information between systems without a central session database.
JWT, explained at three levels
At home
When you log in to an app, you sometimes get a JWT token -- like a signed wristband at a concert. Future requests carry this token; the server reads it to know who you are without looking you up in a database. If the wristband is tampered with, the signature check fails.
At work
JWTs are common in APIs and web apps. After login, the server issues a JWT. The client includes it in subsequent API requests ('Authorization: Bearer <token>'). The server verifies the signature and trusts the claims inside -- no session database lookup needed.
At home
A JWT has three parts separated by dots: Header.Payload.Signature. The header specifies the algorithm (RS256, HS256). The payload contains claims: standard claims (sub, iss, exp, iat, aud) and custom claims (user role, permissions). The signature is a cryptographic hash of the header and payload using a secret or private key. Anyone can decode the payload (it's Base64, not encrypted) -- only the signature prevents tampering.
At work
JWTs are used for: API authentication (bearer tokens), OIDC ID tokens (user identity after SSO), and service-to-service auth (machine-to-machine credentials). Access tokens are short-lived (15 minutes to 1 hour); refresh tokens are longer-lived. JWTs can't be revoked before expiry without a blocklist -- this is a key architectural tradeoff against traditional server-side sessions.
At home
JWT validation requires checking: signature (using the correct algorithm and key), exp (not expired), iss (expected issuer), aud (expected audience), and not trusting algorithm:none. The alg:none vulnerability (accepting unsigned tokens) was a critical flaw in some early implementations. Algorithm confusion attacks (RS256 public key used as HS256 secret) are a known class of JWT vulnerabilities.
At work
In distributed systems, asymmetric JWT signing (RS256, ES256) allows services to verify tokens without a shared secret -- the public key is distributed; only the auth server needs the private key. JWKS (JSON Web Key Sets) endpoints provide the public keys dynamically. Token introspection (RFC 7662) allows opaque tokens with server-side lookup when revocation is needed. DPoP (Demonstrating Proof of Possession, RFC 9449) binds JWTs to specific clients, preventing token theft replay attacks.
Real-world examples
At home
Fatima built an API using JWTs. After login, the API returns a token valid for 1 hour. Her mobile app includes it in every API request header. When the token expires, the app uses a refresh token to get a new one without re-prompting for a password.
At work
Jerome's microservices architecture uses asymmetric JWTs. The auth service signs tokens with its private key; each microservice has the corresponding public key cached locally. Services validate tokens in microseconds without any network call to the auth service.
Common confusions
- JWT payloads are encrypted and private — JWTs are Base64-encoded, not encrypted. Anyone who intercepts a JWT can decode and read its payload. JWTs should be transmitted over HTTPS and must not contain sensitive data like passwords. For encrypted payloads, use JWE (JSON Web Encryption).
- JWTs can be revoked before expiry — Standard JWTs are stateless and valid until expiry. Revoking them requires maintaining a blocklist (a server-side lookup) -- which reintroduces state. This is why access tokens are kept short-lived and refresh tokens can be revoked at the auth server.
For analysts
BAs working with API integrations may encounter JWTs in authentication flows -- understanding their expiry behavior explains why API connections sometimes need re-authorization, and why token scopes matter for what data can be accessed.
History & origin
JWT was standardized as RFC 7519 in 2015, building on earlier work in OAuth 2.0 and JSON Object Signing and Encryption (JOSE). It quickly became the dominant token format for web APIs and SSO systems, replacing older formats like SAML assertions for API-first architectures. JWT's compactness and HTTP-header compatibility made it ideal for stateless microservices and mobile APIs.