JSON Web Tokens (JWT)
A compact, URL-safe token format that encodes claims as a signed JSON payload, enabling stateless authentication between parties.
A JWT is a self-contained token consisting of three Base64-encoded parts: a header (algorithm + type), a payload (claims like user ID, expiration, roles), and a signature. The server signs the token on login and the client sends it with each request. Because the token contains all necessary session data, the server doesn't need to look up a session store -- making it stateless. JWTs are typically signed with HMAC-SHA256 or RSA, and can optionally be encrypted (JWE). They're the backbone of modern API authentication.
Security Model
JWTs rely on cryptographic signatures (HMAC or RSA/ECDSA) to ensure integrity and authenticity. The token payload is not encrypted by default -- it is Base64-encoded and readable by anyone. Security depends on: proper algorithm configuration (preventing algorithm confusion attacks), secure key management, short token lifetimes, secure storage (httpOnly cookies over localStorage), and a revocation strategy for compromised tokens.
Implementation
low complexityUser Experience
Transparent to end users -- they never see the token directly. Login produces a token stored automatically (in cookies or by the client app). Session length is controlled by token expiration and refresh token strategy. Users may experience forced re-authentication when refresh tokens expire, which requires balancing security against convenience.
Platform Examples
Auth0
Issues JWTs as access tokens with RS256 signing. Provides JWKS endpoint for key rotation. Supports custom claims via Rules/Actions pipeline.
Firebase
Firebase Auth issues JWTs verified by Google's public keys. Tokens include user ID, email verification status, and custom claims set by developers.
Stripe
Uses JWTs internally for dashboard session management. API authentication uses long-lived API keys rather than JWTs.
Coinbase
Uses short-lived JWTs for API access tokens with refresh token rotation. Tokens carry account permissions and are validated at the API gateway.
Tradeoffs
Strengths
- Stateless authentication eliminates session store bottleneck
- Horizontally scalable -- any server can validate without shared state
- Self-contained -- carries claims, reducing database lookups
- Widely supported across languages and frameworks
- Works well for API-to-API and microservice communication
Weaknesses
- Revocation is inherently difficult without reintroducing state
- Token size adds overhead to every request (vs 32-byte session ID)
- Payload is visible to anyone (not encrypted by default)
- Clock skew between servers can cause premature expiration or acceptance of expired tokens
- Complexity of key rotation and management at scale
Likely Follow-Up Questions
- How would you handle JWT revocation in a microservice architecture?
- What are the trade-offs between symmetric (HS256) and asymmetric (RS256) JWT signing?
- How do you implement token refresh without creating a window of vulnerability?
- What happens if a JWT signing key is compromised? Walk through your incident response.
- How would you design a JWT-based auth system that supports multi-tenancy?
- What's the difference between JWS, JWE, and JWK, and when would you use each?
Related Auth Methods
Source: editorial — Comprehensive coverage of JWT mechanics, security considerations, and distributed system implications for interview preparation.