Deja de usar JSON Web Tokens para sesiones de usuario

Artículo original ↗ Discusión en Hacker News ↗

Los desarrolladores están debatiendo si los JSON Web Tokens (JWT) son apropiados para gestionar sesiones de usuario en aplicaciones web, especialmente en aplicaciones de una sola página. Muchos sostienen que el problema no son los JWT en sí; los riesgos reales provienen de almacenarlos en lugares accesibles desde JavaScript como `localStorage`, de una protección débil contra XSS y de la dificultad para revocar tokens, lo que lleva a algunos a preferir sesiones tradicionales del lado del servidor o JWT almacenados en cookies `HttpOnly` y `SameSite`. Otros señalan que los JWT siguen teniendo sentido en sistemas distribuidos y APIs, pero subrayan que deben usarse con modelos de amenaza claros, vidas útiles cortas e implementación cuidadosa para evitar errores de seguridad comunes.

Alcance del debate

  • Muchos sostienen que el artículo en realidad trata sobre XSS y las opciones de almacenamiento, no sobre los JWT en sí.
  • Aclaración repetida: JWT es solo un formato de token; puede usarse con cookies u otro almacenamiento, y no es inherentemente opuesto a las “sesiones basadas en cookies”.

Dónde almacenar el estado de la sesión

  • Postura fuerte: almacenar los identificadores de sesión/JWT en cookies HttpOnly, Secure, SameSite.
    • Protege contra el robo directo del token mediante XSS.
    • Evita el cableado manual de cabeceras; el navegador envía las cookies automáticamente.
  • Crítica a localStorage / almacenamiento accesible desde JS:
    • Fácilmente exfiltrable por XSS; especialmente problemático para refresh tokens de larga duración.
    • Algunos frameworks (Firebase, Cognito) usan por defecto local/IndexedDB y no pueden usar HttpOnly.
  • Visión minoritaria: localStorage está “bien” porque XSS significa “fin del juego” de todos modos, y los atacantes aún pueden abusar de las cookies mediante solicitudes dentro del navegador.

CSRF, SameSite y cookies

  • Recomendación: establecer SameSite en cookies sensibles.
    • Lax a menudo se considera suficiente para la protección contra CSRF; Strict puede romper el comportamiento de usuario autenticado en la primera página.
  • Hay cierta confusión sobre cómo interactúan los envíos de formularios entre sitios con las cookies; se señala SameSite como el control.

Modelo de amenaza de XSS

  • Un bando: si se puede inyectar JS, el atacante ya puede actuar como el usuario (hacer solicitudes), así que cookie vs localStorage importa poco.
  • El otro bando: HttpOnly sigue limitando de forma significativa el daño al impedir la exfiltración y reutilización del token desde otro dispositivo; las defensas en capas importan.

Diseño de JWT y revocación

  • Ventajas de JWT citadas:
    • Validación sin estado; bueno para APIs, sistemas distribuidos y microservicios.
    • Los servicios aguas abajo pueden autorizar mediante JWT sin consultar una base de datos de autenticación cada vez.
  • Gran inconveniente: difícil de revocar / cerrar sesión:
    • Patrón típico: access tokens de vida corta + refresh tokens de vida larga, a menudo con refresh tokens opacos y comprobados en la base de datos.
    • Una vez que añades listas de revocación o comprobaciones en la base de datos, pierdes parte de las ventajas de “sin estado”; algunos se preguntan por qué usar JWT en ese punto.
  • Varios recomiendan identificadores de sesión opacos simples en cookies, convirtiendo a JWT solo internamente en los gateways.

Preocupaciones legales / de UX / prácticas

  • Aclaración de que las cookies funcionales/de sesión normalmente no requieren banners de consentimiento; hay confusión en torno a la “cookie directive”.
  • Algunos se quejan de que las directrices de seguridad absolutistas (por ejemplo, timeouts muy cortos) perjudican la usabilidad.
  • Otros critican los artículos de “Deja de usar X” que no ofrecen alternativas claras y prácticas ni matices.