What is JWT (json Web Token)?
JSON Web Token, commonly called JWT, is an open standard for securely transmitting information between parties as a compact JSON object. It’s most often used in web applications to represent claims about a user or a system and to carry authorization information. Unlike a server-side session that stores state on the server, a JWT is self-contained: it carries data (claims) inside the token itself and is cryptographically signed so the receiving party can verify its authenticity without consulting a central store.
How a JWT Is Structured
A JWT is a short string made of three parts separated by dots: header, payload, and signature. The header specifies the token type (JWT) and the signing algorithm (for example, HMAC SHA-256 or RSA). The payload contains claims such as the user id, issuer, subject, audience, issued-at time and expiration time. The signature is produced by combining the header and payload, then signing them with a secret key or private key. Each piece is base64url-encoded so the token can be safely put in an HTTP header or url parameter.
Example token format
header.payload.signature , when decoded, the header and payload are readable JSON objects, while the signature is a cryptographic proof that the token was created by a trusted party and has not been altered.
How JWT Works in an Authentication Flow
The typical flow starts when a client submits credentials (like username and password) to an authentication endpoint. If the credentials are valid, the server issues a JWT that contains user identity and any authorization claims. The client stores this token and includes it on subsequent requests, commonly in the Authorization header as a Bearer token. The server receives the token, verifies the signature and checks claims such as expiration and issuer, then uses the embedded data (for example user ID or role) to decide whether to allow the request. This approach lets servers remain stateless, because the token itself is the proof of authentication.
Signature and Verification: Why It Matters
The signature is the core security mechanism in JWT. When a server or service receives a token, it recomputes the signature using the header and payload and the shared secret (for HMAC) or the public key (for RSA/ECDSA) and compares it to the signature in the token. If they match, the token is intact and was created by a trusted party. Verification also includes checking standard claims like exp (expiration), nbf (not before), iss (issuer), and aud (audience). Proper verification prevents attackers from tampering with the token or forging tokens for unauthorized access.
Common Use Cases for JWT in website Security
JWTs are commonly used for single sign-on (SSO) across multiple services, for stateless API authentication, and for passing identity between microservices. Because they are compact and self-describing, they work well in mobile apps and browser-based clients. They also make horizontal scaling easier: application servers don’t need to maintain a centralized session store, which simplifies deployments in cloud environments.
Benefits and Practical Trade-offs
The main benefits of JWT are compactness, portability, and statelessness. That portability makes it straightforward to authenticate across domains or services without extra session synchronization. However, there are trade-offs to consider. A signed JWT cannot be easily revoked before it expires without additional infrastructure (blacklists or short token windows). If a token is stolen, an attacker can use it until it expires. Because the payload is only base64url-encoded and not encrypted by default, sensitive data should never be stored in the token unless it’s encrypted separately.
Security Risks and Attack Vectors
Several mistakes can undermine JWT security. Storing tokens in localStorage exposes them to cross-site scripting (XSS) attacks. Failing to validate the token’s algorithm or skipping claim checks can enable attacks where tokens are forged or misinterpreted. Using long-lived tokens without refresh or revocation mechanisms increases the window of abuse if a token leaks. Misconfiguring keys (for example allowing unsigned tokens or mixing symmetric and asymmetric verification incorrectly) is another common pitfall.
Best Practices for Using JWT Safely
To use JWT securely in your website or API, adopt a few practical rules: sign tokens using strong algorithms (RS256 or ES256 are recommended if you need asymmetric keys), always validate the signature and the standard claims (exp, nbf, iss, aud), keep tokens short-lived and use refresh tokens or re-authentication to obtain new access tokens, and avoid putting sensitive personal data in the payload. Prefer storing tokens in secure, HttpOnly cookies to reduce XSS risk and ensure https to prevent token interception. Rotate keys periodically and have a plan to revoke or blacklist tokens if needed.
Quick checklist
- Use HTTPS for all token transport.
- Sign tokens; validate signature and critical claims on every request.
- Keep access tokens short-lived; use refresh tokens with secure storage.
- Store tokens in HttpOnly, Secure cookies when possible to mitigate XSS.
- Minimize data in the payload and never store secrets inside a token.
When Not to Use JWT
JWTs are not always the right choice. If you need immediate, server-side revocation of sessions for many users, a server-side session store may be simpler. If your tokens must include large amounts of information, the compact form of JWT might not be ideal and could bloat each request. Evaluate whether the stateless benefits outweigh the operational complexity of key rotation and token invalidation for your specific application.
Summary
JWT is a compact, signed JSON-based token format that enables stateless authentication and information exchange. It works by encoding a header and payload, then attaching a cryptographic signature so receivers can verify authenticity and trust the token’s claims. While JWTs simplify scaling and cross-service authentication, they introduce considerations around storage, token lifetime, revocation and claim validation. With proper signing, short lifetimes, secure storage, and HTTPS, JWT can be a reliable part of a website’s security architecture.
FAQs
Q: Is JWT encrypted?
No , a standard JWT is only base64url-encoded and signed, not encrypted. Anyone who can read the token can decode the header and payload. If you need confidentiality, use JWE (JSON Web Encryption) or encrypt sensitive data before placing it in the token.
Q: How should I store JWTs in a browser?
The safest option is to store tokens in HttpOnly, Secure cookies so JavaScript cannot access them, which helps mitigate XSS attacks. If you store tokens in localStorage or sessionStorage, protect your site thoroughly against XSS and limit token lifetime.
Q: Can a JWT be revoked?
By default a signed JWT cannot be revoked until it expires. To support revocation, implement a token blacklist/denylist on the server, use short-lived access tokens with refresh tokens, or maintain a server-side session map keyed by token identifiers.
Q: Which signing algorithm should I use?
Use strong algorithms. RS256 (RSA) or ES256 (ECDSA) are commonly recommended for asymmetric signing because they separate signing (private key) and verification (public key), which is useful in distributed systems. HMAC (HS256) is simpler but requires securely sharing a symmetric secret among services.
Q: Are JWTs suitable for microservices?
Yes , JWTs are a good fit for microservice architectures because they allow services to verify authentication data without a central session store. Make sure to manage key distribution and rotation carefully and to validate claims consistently across services.
