En este artículo
What Is a JWT?
A JWT (JSON Web Token) is a compact, URL-safe token format used to securely transmit information between parties as a JSON object. Defined by RFC 7519, JWTs are the de facto standard for authentication and authorization in modern web applications and APIs.
JWTs are self-contained — they carry all the information needed to verify the token's authenticity and extract user claims without querying a database. This makes them ideal for stateless authentication in distributed systems and microservice architectures.
JWT Structure
A JWT consists of three Base64URL-encoded parts separated by dots: header.payload.signature.
- Header — a JSON object specifying the token type (JWT) and the signing algorithm (e.g., HS256, RS256, ES256)
- Payload — a JSON object containing claims: registered claims (iss, sub, exp, iat), public claims, and private claims
- Signature — created by signing the encoded header and payload with a secret key (HMAC) or a private key (RSA/ECDSA)
Pruébalo gratis — sin registro
Validar un JWT →How JWT Validation Works
JWT validation involves structural checks, signature verification, and claims validation.
- Structure check — the token must contain exactly three Base64URL-encoded segments separated by two dots
- Header validation — the header must contain valid typ and alg fields. The algorithm must match what the server expects
- Signature verification — the signature is recalculated using the header, payload, and the signing key. If the recalculated signature matches, the token has not been tampered with
- Claims validation — exp (expiration), nbf (not before), and iss (issuer) claims are checked against the current time and expected values
Common Use Cases
JWTs power authentication and authorization across the modern web stack.
- API authentication — clients include JWTs in Authorization headers (Bearer scheme) to authenticate API requests without sessions
- Single sign-on (SSO) — identity providers issue JWTs that multiple applications accept, enabling seamless cross-application authentication
- OAuth 2.0 access tokens — many OAuth implementations use JWTs as access tokens, encoding scopes and permissions directly in the token
- Microservice communication — services pass JWTs to propagate user context and authorization decisions across service boundaries
JWT Security Best Practices
JWTs are powerful but require careful handling to avoid common security pitfalls.
- Always validate the algorithm — never allow the alg field from the token to dictate which algorithm your server uses. This prevents the none algorithm attack
- Set short expiration times — JWTs cannot be revoked once issued. Keep exp times short (15 minutes for access tokens) and use refresh tokens for long-lived sessions
- Use asymmetric algorithms for distributed systems — RS256 or ES256 allow services to verify tokens without sharing the signing secret
- Never store sensitive data in the payload — JWTs are encoded, not encrypted. Anyone can decode the payload. Keep secrets in your database, not in the token
Frequently Asked Questions
Can a JWT be decoded without the secret key?
Yes. JWT payloads are Base64URL-encoded, not encrypted. Anyone can decode and read the header and payload. The secret key is only needed to verify the signature — to confirm the token has not been altered.
What is the difference between JWS and JWE?
JWS (JSON Web Signature) is what most people mean by JWT — a signed token. JWE (JSON Web Encryption) is an encrypted token where the payload cannot be read without the decryption key. Most JWTs are JWS tokens.
Should I store JWTs in localStorage or cookies?
HttpOnly cookies are more secure because they are not accessible via JavaScript (preventing XSS theft). localStorage is vulnerable to XSS attacks. For sensitive applications, use HttpOnly Secure SameSite cookies.