JSON Web Token (JWT): Guía de Autenticación y Seguridad

¿Qué es JWT?

JWT (JSON Web Token) es un formato de token compacto y seguro para URL, definido en RFC 7519, utilizado para intercambio seguro de información entre partes.

JWT consta de tres partes: Header, Payload y Signature. Estas tres partes se separan por puntos (.): xxxxx.yyyyy.zzzzz

Proporciona autenticación sin estado. En lugar de almacenar datos de sesión en una base de datos, el servidor envía el token al cliente. El cliente envía el token con cada solicitud.

Casos de uso: Autenticación API, SSO (Single Sign-On), autenticación entre microservicios, autorización de aplicaciones móviles.

Estructura JWT

Header: Contiene tipo de token (JWT) y algoritmo de firma (HS256, RS256, ES256). Codificado en Base64URL.

Payload: Contiene claims. Registered claims (iss, sub, aud, exp, nbf, iat, jti), public claims y private claims. Codificado en Base64URL.

Signature: El header y payload codificados en Base64URL se unen con un punto y se firman con una clave secreta. HS256 usa HMAC-SHA256, RS256 usa RSA-SHA256.

Ejemplo: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Flujo de uso JWT

1. El usuario envía una solicitud al endpoint de login con nombre de usuario y contraseña.

2. El servidor verifica las credenciales y crea un JWT. El token se devuelve en el body de la respuesta o cookie.

3. El cliente almacena el token en localStorage o cookie httpOnly.

4. En solicitudes posteriores, el cliente envía JWT como Bearer token en el header Authorization: Authorization: Bearer <token>

5. El servidor valida el token (verificación de firma y expiración). Si es válido, procesa la solicitud; si no, devuelve 401 Unauthorized.

Riesgos de seguridad

Robo de token: El token en localStorage puede ser robado mediante ataque XSS. Usa cookie httpOnly para reducir el riesgo XSS.

Vida útil del token: Access token de corta duración (15-30 min) + refresh token de larga duración (7-30 días). Rota el refresh token en cada uso.

Confusión de algoritmo: Algoritmo 'none' o cambio RS256→HS256. Establece el algoritmo como constante en el servidor, no lo tomes del token.

Datos sensibles: El payload JWT está codificado en Base64, no cifrado. No pongas datos sensibles (contraseña, tarjeta de crédito) en el payload.

Tamaño del token: JWT es más grande que la cookie de sesión. Se envía con cada solicitud. Mantén el payload mínimo.

Mejores prácticas

Tokens de corta duración: Access token 15-30 minutos, refresh token 7-30 días. Los tokens expirados se vuelven inválidos automáticamente.

Cookie httpOnly + Secure + SameSite: Almacena el token en cookie httpOnly. JavaScript no puede acceder (protección XSS). Secure (solo HTTPS). SameSite (protección CSRF).

Rotación de token: El refresh token se renueva en cada uso. El refresh token antiguo se vuelve inválido. Limita el acceso del atacante en caso de robo de token.

Blacklist/revocación: Usa blacklist para revocar tokens. Almacena tokens revocados en Redis. Usa para logout e incidentes de seguridad.

Algoritmo: RS256 (asimétrico) recomendado para producción. Firma con clave privada, verifica con clave pública. HS256 (simétrico) solo para un solo servicio.

Validación: Verifica firma, issuer (iss), audience (aud), expiración (exp) en cada solicitud. Asegúrate de que todas las verificaciones pasen antes de confiar en el token.

JWT vs Autenticación basada en sesión

JWT: Sin estado, escalado horizontal fácil, ideal para microservicios, tamaño de token grande, difícil de revocar.

Session: Con estado, requiere almacenamiento del lado del servidor, necesita sticky session o shared store para escalado horizontal, tamaño de token pequeño, fácil de revocar.

Criterios de selección: Arquitectura de microservicios → JWT. Aplicación monolítica → Session. App móvil → JWT. Alto requisito de seguridad → Session + JWT híbrido.

Enfoque híbrido: JWT de corta duración (access token) + session store (refresh token). Combina ventajas de ambos.