Alternativas de seguridad a JWTs: PASETO o Sesiones Server-Side

Durante la última década, los JSON Web Tokens (JWT) se convirtieron en el método de autenticación web. Bajo la promesa de una autenticación completamente stateless (sin estado en el servidor), miles de arquitectos e ingenieros migraron sus sistemas desde las sesiones tradicionales basadas en cookies hacia un esquema donde el cliente almacena un token firmado y lo envía en la cabecera Authorization: Bearer.

Sin embargo, en 2026 la realidad de la producción ha demostrado que la gran mayoría de las implementaciones de JWT en producción sufren de vulnerabilidades criptográficas por diseño o introducen problemas arquitectónicos graves, principalmente por la imposibilidad de revocar un token inmediatamente en caso de robo, la fuga de datos confidenciales en el payload y la complejidad innecesaria para resolver problemas que una sesión centralizada resuelve en milisegundos.

Es por ello que en este artículo analizamos por qué el modelo JWT tradicional está desactualizado y presentamos las dos alternativas modernas: PASETO (Platform-Agnostic Security Tokens) y el retorno pragmático a las Sesiones Server-Side optimizadas en memoria.

1. La inseguridad por diseño de los JWT (JOSE Standards)

El estándar JWT forma parte de la familia JOSE (JSON Object Signing and Encryption). Aunque en teoría es flexible, esa misma flexibilidad es su mayor debilidad de seguridad:

A. La vulnerabilidad del algoritmo "alg": "none"

El encabezado (header) de un JWT le dice al servidor qué algoritmo usar para verificar la firma. Históricamente, esto permitió ataques donde un atacante modificaba el encabezado para especificar "alg": "none", firmaba el token de forma nula y muchos servidores desactualizados aceptaban el token como válido, permitiendo la suplantación de cualquier usuario.

B. Confusión de claves (Key Confusion Attack)

Si un servidor acepta algoritmos asimétricos (RS256) y simétricos (HS256), un atacante puede tomar la clave pública del servidor (disponible abiertamente) y firmar un token malicioso usando HS256 utilizando la clave pública como si fuera la clave secreta simétrica. Si el backend no valida estrictamente el algoritmo, el token se da por válido.

C. El mito del "Stateless" y la imposibilidad de revocación

Si un usuario cierra sesión, si se cambian sus permisos en la base de datos o si su cuenta es comprometida, un JWT no se puede revocar de forma nativa antes de que caduque.

Para revocarlo, los equipos terminan implementando una "lista negra" (blacklist) de tokens revocados guardada en tu sistema de sessión o cache como Redis. En el instante en que consultas Redis en cada petición para comprobar si el token es válido, tu autenticación ha dejado de ser stateless y has vuelto a una sesión en servidor, pero con la complejidad adicional de guardar tokens criptográficos masivos en lugar de identificadores simples.

2. Opción 1: PASETO (Platform-Agnostic Security Tokens)

Para casos de uso donde realmente necesitas tokens firmados para la comunicación entre microservicios o APIs de terceros, PASETO es el sustituto moderno y seguro que corrige los errores de diseño de JOSE/JWT.

JWT (Inseguro por flexibilidad):
[ Header: {"alg": "HS256"} ] . [ Payload ] . [ Signature ]  --> Propuesto a fallos de configuración

PASETO (Seguro por defecto):
v4.local. [ Payload Encriptado + MAC ]                        --> Algoritmos fijos y probados

¿Por qué PASETO es superior a JWT?

1. Sin elección de algoritmo (No Algorithm Agility): En PASETO no existe un encabezado donde el usuario elija el algoritmo. Cada versión de PASETO utiliza un conjunto cerrado y seguro de primitivas criptográficas probadas (ej. versión v4.local usa ChaCha20-Poly1305 para simétrico; v4.public usa Ed25519 para asimétrico). Esto elimina por completo los ataques por confusión de claves o algoritmos "none".
2. Cifrado garantizado en tokens locales: A diferencia de un JWT donde el payload está codificado en Base64 simple (cualquiera puede leer los datos si obtiene el token), las versiones local de PASETO cifran el contenido por defecto.
3. Firmas fuertes: No hay cabida para implementaciones obsoletas. Toda la criptografía cumple con los estándares más estrictos del software moderno.

3. Opción 2: El retorno a las Sesiones Server-Side (Redis)

Si estás construyendo una aplicación web o un SaaS monolítico / monolítico modular como vimos en nuestro en Arquitectura backend: El Monolito modular en 2026, las sesiones en servidor siguen siendo la solución más segura, simple y fácil de mantener.

[Cliente]  ──(Cookie HTTPOnly / SameSite / Secure)──►  [API Gateway / Server]
                                                            │
                                                            ▼ (Búsqueda en memoria: <1ms)
                                                       [Redis Cluster / Sessions]

La Arquitectura de Sesión Moderna:

1. Identificador aleatorio de alta entropía: El cliente solo recibe un ID de sesión criptográficamente aleatorio guardado en una cookie con las marcas HttpOnly, Secure y SameSite=Strict (lo que impide que scripts maliciosos de JavaScript roben el token vía XSS).
2. Almacenamiento en memoria de alta velocidad: Las sesiones se almacenan en un clúster de Redis o KeyDB. Como analizamos en nuestro Arquitectura backend: Estrategias avanzadas de caché e invalidation, la lectura de una clave en Redis toma menos de un milisegundo ($<1\text{ms}$).
3. Revocación inmediata y control total: ¿El usuario hace clic en "Cerrar sesión en todos los dispositivos"? Se borran sus claves en Redis. ¿Se le revoca el rol de administrador? Se actualiza la sesión al instante. Cero problemas de sincronización o ventanas de vulnerabilidad.

4. Matriz comparativa: JWT vs. PASETO vs. Server-Side Sessions

Conclusión

En 2026, seguir utilizando JWTs para la autenticación de usuarios en aplicaciones web convencionales es introducir complejidad técnica y riesgos de seguridad sin recibir ninguna ventaja real a cambio.

Para la inmensa mayoría de las aplicaciones, el uso de sesiones en servidor respaldadas por Redis ofrece la máxima seguridad, revocación inmediata y protección contra ataques XSS. Si tu arquitectura distribuida exige tokens firmados entre servicios, la respuesta no es un JWT con librerías inseguras, sino dar el paso hacia PASETO.

Referencias:
· JSON Web Token Best Current Practices.
· OWASP Cheat Sheets