Deja de usar JWTs

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

Alcance del debate

  • La mayoría de los participantes distingue dos casos de uso principales:
    • Sesiones de usuario basadas en navegador.
    • Tokens de servicio a servicio / backend.
  • Consenso suave general: los JWTs suelen ser una mala opción para sesiones de navegador, pero pueden estar bien o incluso ser ideales para escenarios de backend y federación.

JWTs para sesiones basadas en navegador

  • Los críticos dicen que los JWTs añaden complejidad frente a simples IDs de sesión opacos en cookies HttpOnly, sin un beneficio real si el mismo servidor los emite y valida.
  • Principales problemas señalados:
    • Revocación y cierre de sesión difíciles o incómodos, especialmente el cierre de sesión por dispositivo.
    • Posibilidad de repetición y tokens de larga duración.
    • Tendencia a meter datos sensibles o mutables en los tokens, creando problemas de invalidación de caché y de seguridad.
  • Varios sostienen: si ya necesitas un datastore (para usuarios, permisos), simplemente guarda el estado de la sesión allí y evita la criptografía para las sesiones.

Propiedades de seguridad y trampas de implementación

  • Problemas históricos: alg=none, degradación/confusión de algoritmos, bibliotecas que aceptan claves públicas como secretos HMAC, malos valores por defecto.
  • Algunos dicen que estos fueron errores de las bibliotecas y en su mayoría ya están corregidos; otros sostienen que provienen de una especificación que fomenta trampas y complejidad.
  • Desacuerdo sobre cuán “inseguro” es JWT hoy:
    • Un bando: “JWT está bien si restringes los algoritmos y usas buenas bibliotecas.”
    • Otro bando: “La especificación fomenta usos incorrectos; siguen apareciendo CVEs; existen diseños más seguros.”

Revocación, autenticación “sin estado” y cierre de sesión

  • Tensión central: los JWTs se comercializan como “sin estado”, pero el cierre de sesión seguro y el manejo de compromisos requieren estado:
    • Listas de revocación / denylists.
    • Marcas de tiempo por usuario de “no válido antes de”.
    • Esquemas de rotación de claves.
  • Algunos argumentan que una vez añades ese estado, has perdido la principal ventaja frente a las sesiones clásicas.
  • Otros responden que las listas de revocación son mucho más pequeñas que los almacenes completos de sesiones y más fáciles de replicar globalmente.

Cookies, almacenamiento y XSS/CSRF

  • Fuerte apoyo a cookies HttpOnly, Secure, SameSite para sesiones de navegador.
  • Muchos advierten contra almacenar JWTs en localStorage debido a la exfiltración por XSS; algunos restan importancia a esto si “no permites JS no confiable”, otros dicen que eso no es realista.
  • Se señala que HttpOnly evita el robo del token pero no el uso malicioso impulsado por XSS.

Alternativas y ecosistema más amplio

  • Alternativas mencionadas: tokens opacos aleatorios, cookies firmadas, PASETO, macaroons, patrones SAML/OIDC, esquemas personalizados.
  • Algunos elogian los diseños de PASETO/macaroons como más resistentes a usos incorrectos, pero señalan un ecosistema y una adopción limitados.
  • Varios consideran que el planteamiento “deja de usar JWTs” es exagerado o sensacionalista; prefieren “usa JWTs de forma limitada y cuidadosa.”