JWT - Tokens web JSON para autenticación
Lectura de 2 min aprox.
Un JWT (JSON Web Token) es un token que codifica datos en formato JSON en una cadena compacta con una firma digital adjunta. Estandarizado como RFC 7519 en 2015, se utiliza ampliamente como token de acceso de OAuth 2.0 y como aserción para el inicio de sesión único (SSO). Su mayor característica es que permite una autenticación sin estado que no conserva la información de sesión en el lado del servidor, y su adopción se expandió rápidamente junto con la difusión de la arquitectura de microservicios.
Estructura de 3 partes - Header.Payload.Signature
Un JWT consta de tres partes separadas por puntos (.). Cada parte está codificada en Base64URL y no puede ser leída directamente por humanos, pero una vez decodificada se puede inspeccionar su contenido como JSON.
La diferencia entre JWS y JWE
El término JWT se usa comúnmente con el sentido de «token firmado», pero según la especificación existen dos tipos: JWS (JSON Web Signature) y JWE (JSON Web Encryption).
El payload solo está codificado en Base64URL, por lo que cualquiera puede leer su contenido al decodificarlo. La firma permite detectar manipulaciones, pero no puede mantener el contenido confidencial. La gran mayoría de lo que generalmente se llama «JWT» es este formato JWS.
El payload en sí se cifra, de modo que solo quienes poseen la clave de descifrado pueden leer su contenido. Adopta una estructura de 5 partes (Header, Encrypted Key, IV, Ciphertext, Authentication Tag). Se usa cuando es necesario incluir información confidencial en el token.
En la práctica, JWS se usa con mucha más frecuencia. La premisa es que no se incluyen datos personales ni confidenciales en el payload; si es necesario incluir tales datos, conviene considerar JWE o, mejor aún, revisar el diseño para que no se incluyan en el token en absoluto.
Ventajas y riesgos de la autenticación sin estado
Con la autenticación sin estado mediante JWT, el servidor no conserva información de sesión. Como la autenticación se completa con solo verificar la firma del token, no es necesario gestionar los tokens de sesión en Redis o en una base de datos, lo que facilita el escalado horizontal.
| Aspecto | JWT (sin estado) | Sesión por cookie (con estado) |
|---|---|---|
| Estado del lado del servidor | Ninguno (el propio token contiene la información) | Presente (se requiere un almacén de sesiones) |
| Escalabilidad | Alta (verificable en cualquier servidor) | Se requiere un mecanismo de compartición de sesiones |
| Revocación inmediata | Difícil (se requiere un esquema de lista negra) | Fácil (basta con eliminar la sesión) |
| Tamaño del token | Grande (de cientos de bytes a varios KB) | Pequeño (solo el ID de sesión) |
| Resistencia a CSRF | Resistente al usar el encabezado Authorization | Se requieren contramedidas como el atributo SameSite |
El mayor riesgo es que «un JWT, una vez emitido, no puede revocarse de inmediato». Aunque el usuario cambie su contraseña, un JWT filtrado puede seguir usándose hasta que caduque. Para mitigar este problema, un patrón habitual es establecer una expiración corta para el token de acceso (unos 15 minutos) y reemitirlo con un token de actualización. En requisitos donde la revocación inmediata sea obligatoria, conviene mantener una lista negra en el lado del servidor o elegir una gestión de sesiones basada en cookies.
Ataques representativos que tienen como objetivo los JWT
Un ataque que reescribe el campo alg del Header a "none" para eludir la verificación de la firma. Muchas bibliotecas tempranas tenían implementaciones que aceptaban alg:none. Como contramedida, incluya explícitamente en una lista blanca los algoritmos permitidos en el lado del servidor.
Un ataque que reescribe el alg de un token firmado con RS256 (clave asimétrica) a HS256 (clave simétrica) y usa la clave pública como la clave secreta de HMAC. Como la clave pública está disponible para cualquiera, un atacante puede generar una firma válida.
Si la clave secreta de HS256 es una cadena corta o un valor adivinable, la clave puede identificarse por fuerza bruta. Es esencial usar una clave aleatoria de al menos 256 bits y rotarla periódicamente.
Las técnicas del secuestro de sesión también se aplican a los JWT. Es importante comprenderlas junto con los fundamentos del cifrado. Consulte también las contramedidas contra el secuestro de sesión, las defensas contra el robo de tokens de sesión y las mejores prácticas para la gestión de claves de API.libros sobre autenticación web (Amazon) se recomiendan para un aprendizaje sistemático.
¿Te resultó útil este artículo?