JWT

Qué es

JWT significa JSON Web Token. Está definido en el RFC 7519 (IETF, 2015), que sugiere pronunciarlo como la palabra inglesa jot (en español, algo como “yot”). Es uno de los formatos más usados para transmitir información de identidad y permisos entre sistemas.

Cuando una API dice que necesitas un “token” para autenticarte, con mucha frecuencia ese token es un JWT (aunque también existen tokens opacos).

La estructura de un JWT

Un JWT tiene 3 partes separadas por puntos:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibm9tYnJlIjoiQW5hIEdhcmPDrWEiLCJyb2wiOiJhZG1pbiIsImlhdCI6MTY0MDAwMDAwMCwiZXhwIjoxNjQwMDA3MjAwfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

(Header y payload reales codificados en Base64URL; la firma es ilustrativa.)

1. Header (Encabezado)

Indica el algoritmo de firma usado:

{
  "alg": "HS256",
  "typ": "JWT"
}

2. Payload (Carga útil)

Los datos que queremos transmitir:

{
  "sub": "1234567890",
  "nombre": "Ana García",
  "rol": "admin",
  "iat": 1640000000,
  "exp": 1640007200
}

3. Signature (Firma)

Garantiza que el token no fue modificado. Se calcula sobre header + payload con una clave secreta compartida (HS256) o con una clave privada (RS256, ES256).

Cómo funciona la autenticación con JWT

1. Usuario hace login (email + password)
         ↓
2. Servidor verifica credenciales
         ↓
3. Servidor genera JWT firmado con clave secreta
         ↓
4. Servidor envía JWT al cliente
         ↓
5. Cliente guarda JWT (en web, idealmente en una cookie HttpOnly y Secure)
         ↓
6. En cada petición, se envía el JWT (cookie o header Authorization: Bearer <JWT>)
         ↓
7. Servidor verifica la firma → si válida, procesa la petición

Ventajas del JWT

Ventaja	Descripción
Sin estado	El servidor no necesita guardar sesiones en base de datos
Portable	El mismo token funciona en múltiples servicios
Auto-contenido	El token lleva la información del usuario — no hay que consultarla
Verificable	Con algoritmos asimétricos (RS256/ES256), cualquier servicio con la clave pública puede verificarlo sin conocer la clave privada

Campos estándar del Payload

Campo	Nombre	Descripción
`sub`	Subject	Identificador del usuario
`iss`	Issuer	Quién emitió el token
`aud`	Audience	Para quién es el token
`exp`	Expiration	Cuándo vence
`iat`	Issued At	Cuándo fue emitido
`nbf`	Not Before	Desde cuándo es válido

Buenas prácticas de seguridad

✅ Hacer:

Usar tiempos de expiración cortos (exp), combinados con refresh tokens
Transmitir siempre por HTTPS
Almacenar tokens en cookies HttpOnly para webs (no en localStorage, expuesto a XSS)
Validar siempre firma, exp, iss y aud, y fijar en el servidor qué algoritmos se aceptan (nunca alg: none)
Usar algoritmos asimétricos (RS256/ES256) cuando varios servicios verifican tokens; HS256 es válido si un solo servicio emite y verifica, con un secreto robusto

❌ No hacer:

Guardar datos sensibles en el payload (en un JWT firmado solo está codificado en Base64URL, no cifrado)
Crear tokens que nunca expiran
Transmitir por HTTP sin cifrado

JWT vs Sesiones tradicionales

Aspecto	Sesión tradicional	JWT
Almacenamiento	En servidor (DB o Redis)	En cliente (token)
Escalabilidad	Requiere sesiones compartidas	Cualquier servidor puede verificar
Revocación	Inmediata (borra la sesión)	Compleja (esperar a que expire o mantener una lista de revocación)
Tamaño	ID pequeño	Token más grande
Idóneo para	Apps web tradicionales	APIs, microservicios, apps móviles

Términos relacionados

API - Las APIs usan JWT para autenticar quién hace cada petición
REST - Las APIs REST usan JWT en el header Authorization
Shift-Left Security - La seguridad de tokens debe pensarse desde el diseño
Microservices - JWT permite que múltiples servicios validen identidad sin coordinación central

Recursos adicionales:

RFC 7519 - Especificación oficial de JWT
JWT.io - Decodificador visual de tokens JWT
Auth0 - Introducción a JWT

Pronunciación