What is a JSON Web Token (JWT)?
A JSON Web Token (JWT) is a compact and self-contained standard (defined in RFC 7519) used to securely share claims and information between a client and a server. In modern web development, JWTs are most commonly used for user authentication and authorization. After a user successfully logs in, the authentication server generates a JWT containing their identity and permissions, which the client then attaches to subsequent API requests (typically in the Authorization: Bearer <token> header).
Unlike session state or database tokens, JWTs are stateless. All necessary details are embedded directly inside the token itself, reducing database lookups and improving application performance.
JWT Structure Explained: Header, Payload, and Signature
A JSON Web Token in its compact format consists of three base64url-encoded parts separated by dots (.):
1. Header (Red)
Contains configuration metadata about the token, such as the token type (usually JWT) and the cryptographic signing algorithm (such as HS256 or RS256).
2. Payload (Purple)
Contains the actual statements (claims) being transmitted. This is where user metadata (e.g. user ID, name, permissions) and token validity settings (issue time, expiry) are placed.
3. Signature (Cyan)
Generated by hashing the encoded Header and Payload together with a secret key or private key. It verifies that the token's content was not tampered with during transit.
JWT vs. Session Authentication
Traditional web applications use stateful session authentication. When a user logs in, the server stores a session record in memory or database and returns a Session ID inside a cookie. On subsequent requests, the server reads the cookie, searches for the Session ID in its storage, and fetches user details.
In contrast, JWT authentication is stateless. The server stores no session records. The JWT itself contains all the claims (like user ID and access level). The server simply verifies the cryptographic signature of the token on each incoming request. If the signature is valid and the expiration time has not passed, the server trusts the details inside the token. This makes JWTs ideal for microservices, mobile apps, and horizontal scaling.
Common JWT Claims & Security Best Practices
Registered claims are crucial for securing your token implementation. Follow these developer best practices when designing token workflows:
- Set short expiration times: Always define an
expclaim (Expiration Time). Standard access tokens should expire within minutes (e.g. 15 minutes) to minimize the impact of compromised tokens. - Implement Token Replay Defense: Use the
jticlaim (JWT ID) to provide a unique token identifier, and store validated IDs in a fast cache (like Redis) to prevent replay attacks during the active token window. - Validate the Audience: Set the
audclaim (Audience) to ensure that the token is only accepted by the specific microservices or applications it was generated for. - Do not store sensitive details: Remember that JWTs are only base64url encoded, meaning **anyone can decode and read them**. Never store passwords, API secrets, or personally identifiable information (PII) inside the header or payload.
- Keep secrets secure: Signature algorithms like HMAC-SHA256 rely on a secure secret key. Use long, random strings for secrets, and store them securely in environment configurations, not in code.