JSON Web Token (JWT)
Home /
Glossary Index /
Alphabet J
JSON Web Token (JWT)
Traditional web applications store session data on the server. Each request requires a database lookup. This creates scalability bottlenecks. JSON Web Tokens (JWT) solve this problem. The token contains all the information needed to authenticate users. Servers validate signatures without database queries. Stateless authentication scales effortlessly. But JWTs introduce new security risks. Here is what you need to know.
What Is a JSON Web Token?
JSON Web Token (JWT) is an open standard (RFC 7519) for creating compact, self-contained tokens that securely transmit information between parties as a JSON object. JWTs are commonly used for authentication and information exchange in web applications and APIs. The token contains all required information about an entity, eliminating the need for server-side session storage. The recipient validates the token without calling a database.
JWT Structure: Three Parts
A JWT consists of three Base64URL-encoded parts separated by dots:
JWT Structure: header.payload.signature
| JWT Component | Purpose | Example Content |
|---|---|---|
| Header | Contains the token type (JWT) and the signing algorithm used (e.g., HMAC SHA256 or RSA). |
{"alg":"HS256","typ":"JWT"}
|
| Payload (Claims) | Contains claims about the user or entity, including standard claims such as subject (sub), expiration time (exp), issuer (iss), and issued at (iat). |
{"sub":"1234567890","name":"John Doe","exp":1516239022}
|
| Signature | Verifies token authenticity and ensures the token has not been altered. | Generated by signing the header and payload with a secret or private key. |
How JWT Authentication Works
Step 1: User Logs In
The user submits credentials to the authentication server. The server validates the credentials.
Step 2: Server Issues JWT
The server creates a JWT containing user identity and expiration time. It signs the token with a secret key.
Step 3: Client Stores Token
The client stores the JWT (local storage, cookies, or memory). The token gets sent with every subsequent request.
Step 4: Server Validates Token
For each request, the server validates the signature, checks expiration, and extracts user identity. No database lookup required.
Step 5: Token Expires
The token automatically expires after the specified time. The user must re-authenticate to obtain a new token.
4 Critical JWT Security Considerations
Consideration 1: Always Verify the Signature
Never trust a JWT without verifying its signature. Attackers can modify claims if they can generate valid signatures. Signature verification prevents tampering.
Consideration 2: Validate the Algorithm
Some attacks trick servers into accepting tokens with “none” as the algorithm. The server skips signature verification entirely. Always validate that the algorithm matches your expected value.
Consideration 3: Check Expiration
Expired tokens should be rejected. The “exp” claim specifies the token’s expiration time. Enforce this check on every request.
Consideration 4: Use HTTPS
JWTs transmit sensitive claims in the payload. Anyone intercepting the token can read user information. Always use HTTPS to prevent token interception.
Common JWT Use Cases
Use Case 1: Stateless Authentication
Traditional session authentication stores data on the server. This does not scale horizontally. JWT authentication is stateless. Any server can validate tokens. Scaling becomes trivial.
Use Case 2: Single Sign-On (SSO)
A user authenticates once with an identity provider. The provider issues a JWT. Service providers validate the token without additional authentication. Users access multiple applications with one login.
Use Case 3: API Authentication
APIs receive JWTs with each request. The API validates the token and extracts user permissions. No session management overhead. Rate limiting and auditing become straightforward.
Use Case 4: Information Exchange
JWTs securely transmit claims between parties. Both parties trust the signature. The token contains all necessary information. No additional API calls required.
5 Common JWT Implementation Mistakes
Mistake 1: Storing Sensitive Data in Payload
JWT payloads are base64-encoded, not encrypted. Anyone can decode and read the contents. Never store passwords, credit cards, or personal data in JWTs.
Mistake 2: Long Expiration Times
Tokens that never expire create infinite session risks. Short expiration times (15-60 minutes) limit damage from stolen tokens. Use refresh tokens for long-lived sessions.
Mistake 3: No Token Revocation
Stateless authentication has no built-in revocation. Stolen tokens remain valid until expiration. Implement a token blacklist or use short-lived tokens.
Mistake 4: Weak Signing Keys
A weak secret key allows attackers to forge signatures. Use strong, random secrets (minimum 32 bytes). Store keys securely, separate from code.
Mistake 5: Storing Tokens Insecurely
Local storage is vulnerable to XSS attacks. Cookies with HttpOnly and Secure flags offer better security. Choose token storage based on your threat model.
JWT vs Traditional Sessions
| Aspect | JWT | Traditional Sessions |
|---|---|---|
| State | Stateless | Stateful |
| Scalability | Excellent (no shared storage) | Requires shared session store |
| Token Size | Large (includes all claims) | Small (just session ID) |
| Revocation | Difficult (must wait for expiration) | Easy (delete session record) |
| Cross-Domain | Works naturally | Requires special configuration |
JWTs excel at authentication across distributed systems. They fail at scenarios requiring immediate revocation or handling large claims. Choose JWT for APIs, microservices, and SSO. Choose traditional sessions for applications requiring granular session control. Neither is universally better. Choose based on your specific requirements.
