JWT
JSON Web Token (JWT) is a compact, URL-safe token format for representing claims between parties. It is commonly used for API authentication (Bearer tokens), OAuth 2.0 access tokens, and OIDC ID tokens.
§ 1 Definition
JWT is an open standard (RFC 7519) that defines a self-contained way to transmit information between parties as a JSON object. The token is digitally signed (usually with HMAC or RSA/ECDSA) so the receiver can verify the sender's identity and detect tampering. A JWT consists of three parts: a header (algorithm and token type), a payload (claims like user ID, roles, expiration), and a signature. These are base64url-encoded and separated by periods (xxx.yyy.zzz). JWTs are popular for stateless authentication because the server does not need to maintain session state the token itself contains all needed information.
§ 2 JWT Structure
A JWT has three Base64Url-encoded segments separated by dots. Header: specifies the signing algorithm (e.g., HS256, RS256) and token type. Payload: contains claims (registered claims like iss, sub, exp, iat; public claims; private claims). Signature: generated by applying the algorithm to the header and payload using a secret (HMAC) or private key (RSA/ECDSA). Example: `eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.NHVZR7...`
§ 3 Security Considerations
Never store secrets in the payload: JWTs are signed, not encrypted. Anyone with the token can base64-decode the payload. Use JWE (JSON Web Encryption) if you need confidentiality. Validate the signature: Always verify the JWT signature on the server. Check the expiration: The `exp` claim must be validated. Do not accept expired tokens. Use short expiration times: 15 minutes is standard for access tokens. Use refresh tokens for longer sessions. Algorithm confusion attacks: Explicitly whitelist allowed algorithms on the server. Never accept 'none' algorithm tokens.
§ 4 JWT vs Session Cookies
JWTs enable stateless authentication: no server-side session storage, easy to use across multiple services (microservices), natural fit for mobile and SPA clients. However, stateless JWTs cannot be revoked (no way to invalidate an unexpired token server-side). Session cookies are stateful: revokable, simpler to manage, but require shared session storage across services. A common pattern is short-lived JWTs (15 min) with refresh tokens that can be revoked, or using a token blacklist for JWT revocation.
§ 5 Note
§ 6 Common questions
- Q. Can JWT tokens be revoked?
- A. JWTs are stateless. An issued token remains valid until it expires. To revoke, you need a blacklist or a database check on every request, which defeats the statelessness benefit. Use short expiration times and revokable refresh tokens instead.
- Q. Where should JWT tokens be stored on the client?
- A. HTTP-only, Secure, SameSite cookies are the most secure option. localStorage is accessible to XSS attacks. Bearer tokens in Authorization headers (for API clients) are also acceptable.
- Q. What is the difference between JWT and OAuth?
- A. JWT is a token format. OAuth 2.0 is an authorization framework that can use JWTs as access tokens. They are complementary, not competing.
- JWT is a signed, self-contained token format for transmitting claims.
- Always validate the signature, algorithm, and expiration on the server.
- JWTs are not encrypted by default. Do not put sensitive data in the payload.
- Short expiration times + revokable refresh tokens mitigate the revocation problem.
Atomic Glue implements JWT-based authentication with secure token handling, short expiration windows, refresh token rotation, and algorithm enforcement. We avoid common JWT pitfalls. Get in touch.
Get in touchJSON Web Token (JWT) is a compact, URL-safe token format for representing claims between parties. It is commonly used for API authentication (Bearer tokens), OAuth 2.0 access tokens, and OIDC ID tokens.
Category: Security (also: Web Development, Apis)
Author: Atomic Glue Security Team
## Definition
JWT is an open standard (RFC 7519) that defines a self-contained way to transmit information between parties as a JSON object. The token is digitally signed (usually with HMAC or RSA/ECDSA) so the receiver can verify the sender's identity and detect tampering. A JWT consists of three parts: a header (algorithm and token type), a payload (claims like user ID, roles, expiration), and a signature. These are base64url-encoded and separated by periods (xxx.yyy.zzz). JWTs are popular for stateless authentication because the server does not need to maintain session state the token itself contains all needed information.
## JWT Structure
A JWT has three Base64Url-encoded segments separated by dots. **Header**: specifies the signing algorithm (e.g., HS256, RS256) and token type. **Payload**: contains claims (registered claims like iss, sub, exp, iat; public claims; private claims). **Signature**: generated by applying the algorithm to the header and payload using a secret (HMAC) or private key (RSA/ECDSA). Example: `eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.NHVZR7...`
## Security Considerations
**Never store secrets in the payload**: JWTs are signed, not encrypted. Anyone with the token can base64-decode the payload. Use JWE (JSON Web Encryption) if you need confidentiality. **Validate the signature**: Always verify the JWT signature on the server. **Check the expiration**: The `exp` claim must be validated. Do not accept expired tokens. **Use short expiration times**: 15 minutes is standard for access tokens. Use refresh tokens for longer sessions. **Algorithm confusion attacks**: Explicitly whitelist allowed algorithms on the server. Never accept 'none' algorithm tokens.
## JWT vs Session Cookies
JWTs enable stateless authentication: no server-side session storage, easy to use across multiple services (microservices), natural fit for mobile and SPA clients. However, stateless JWTs cannot be revoked (no way to invalidate an unexpired token server-side). Session cookies are stateful: revokable, simpler to manage, but require shared session storage across services. A common pattern is short-lived JWTs (15 min) with refresh tokens that can be revoked, or using a token blacklist for JWT revocation.
## Note
The JWT 'none' algorithm vulnerability is a classic attack where an attacker changes the header from RS256 to 'none' and removes the signature. Always validate algorithm enforcement on the server.
## Common questions
Q: Can JWT tokens be revoked?
A: JWTs are stateless. An issued token remains valid until it expires. To revoke, you need a blacklist or a database check on every request, which defeats the statelessness benefit. Use short expiration times and revokable refresh tokens instead.
Q: Where should JWT tokens be stored on the client?
A: HTTP-only, Secure, SameSite cookies are the most secure option. localStorage is accessible to XSS attacks. Bearer tokens in Authorization headers (for API clients) are also acceptable.
Q: What is the difference between JWT and OAuth?
A: JWT is a token format. OAuth 2.0 is an authorization framework that can use JWTs as access tokens. They are complementary, not competing.
## Key takeaways
- JWT is a signed, self-contained token format for transmitting claims.
- Always validate the signature, algorithm, and expiration on the server.
- JWTs are not encrypted by default. Do not put sensitive data in the payload.
- Short expiration times + revokable refresh tokens mitigate the revocation problem.
## Related entries
- [OAuth 2.0](atomicglue.co/glossary/oauth-20)
- [Authentication vs Authorization](atomicglue.co/glossary/authentication-vs-authorization-backend)
- [CSRF](atomicglue.co/glossary/csrf)
Last updated December 2024. Permalink: atomicglue.co/glossary/jwt-security