Deja de usar JWTs cuando estorban

JWT no es malo por definición. El problema aparece cuando lo metes en un stack porque sí, como si fuera el único camino para autenticar usuarios. Muchas veces termina resolviendo un problema simple con una pieza que complica revocación, sesiones, rotación de credenciales y control de acceso.

Si trabajas en un producto real, con usuarios que cierran sesión, cambian contraseña, pierden el teléfono o necesitan que les mates todas las sesiones activas, ahí es donde JWT empieza a estorbar. No porque sea imposible hacerlo bien, sino porque el costo operativo sube rápido y el beneficio no siempre compensa.

Por qué JWT se volvió el default

JWT ganó popularidad porque encaja bien con arquitecturas distribuidas. Puedes firmar un token, enviarlo al cliente y validar su integridad sin consultar una base de datos en cada request. Eso suena limpio, especialmente cuando estás armando APIs, microservicios o frontends desacoplados.

El problema es que muchos equipos confundieron “útil en ciertos casos” con “útil para todo”. Empezaron a usar JWT incluso en aplicaciones donde una sesión tradicional con cookie segura resolvía el 90% del problema con menos superficie de ataque y menos lógica de soporte.

La documentación oficial de JWT deja claro que el estándar está pensado para transportar claims de forma compacta y verificable, no para reemplazar toda la lógica de sesión de cualquier sistema. Si quieres revisar la base técnica, puedes leer RFC 7519 y la guía de cookies de MDN para comparar enfoques.

Qué promete JWT en la práctica

En teoría, JWT te da tres cosas: portabilidad, verificación de firma y menos dependencia del servidor para validar identidad. En un sistema con varios servicios, eso puede ser útil si realmente necesitas que cada servicio valide el token sin hablar con un auth server central en cada request.

Pero ojo con el costo oculto. Si el token vive mucho tiempo, revocarlo es difícil. Si vive poco tiempo, necesitas refresh tokens, rotación, almacenamiento seguro y más casos borde. Si además lo guardas mal en el frontend, abres la puerta a robo por XSS o a una implementación frágil con localStorage.

El error más común: usarlo para todo

El patrón típico es este: una app web simple, un backend monolítico, un panel de administración y un login básico. Aun así, alguien propone JWT “porque es lo moderno”. Resultado: access token, refresh token, blacklist, expiración, rotación, logout parcial, logout global y un montón de código para resolver algo que una sesión server-side hacía mejor.

En productos pequeños y medianos, esa complejidad no solo cuesta tiempo. También cuesta soporte. Cada incidente de seguridad o de sesión termina con preguntas como “¿este token seguía vivo?”, “¿se rotó bien?” o “¿por qué el usuario sigue autenticado después de cambiar su contraseña?”.

Cuándo JWT sí tiene sentido

JWT sí puede encajar cuando tienes servicios separados que necesitan verificar identidad sin depender de una llamada central en cada request. También puede servir si consumes una API desde múltiples clientes y quieres que el token lleve claims útiles, como roles, tenant o permisos básicos.

Otro caso razonable es cuando la validación distribuida importa más que la revocación instantánea. Por ejemplo, accesos de corta duración en sistemas internos, o integraciones donde el token se usa como credencial de intercambio entre servicios y no como sesión principal del usuario.

La clave no es si JWT existe o no, sino si su ventaja concreta supera sus costos. Si no puedes explicar por qué necesitas una credencial autosuficiente, probablemente estás usando JWT por inercia.

Casos donde aporta valor real

• Microservicios donde cada servicio valida firma y expiración localmente.
• APIs públicas con clientes diversos, donde el token viaja entre dominios o plataformas.
• Integraciones B2B con claims claros y duración corta.
• Gateways que necesitan autorización rápida sin consultar una base central en cada request.

Casos donde no aporta tanto

• Paneles administrativos internos.
• Apps web monolíticas con backend propio.
• Sistemas donde necesitas revocación inmediata.
• Productos con soporte frecuente de “cerrar sesión en todos los dispositivos”.

Si tu caso cae en el segundo grupo, JWT suele ser más carga que ayuda.

El problema real: revocación, sesiones y seguridad

JWT no tiene estado por diseño. Eso es bueno para escalar validación, pero malo cuando necesitas invalidar credenciales antes de que expiren. Si un token dura 15 minutos, durante esos 15 minutos sigue siendo válido aunque hayas deshabilitado al usuario, revocado acceso o detectado actividad sospechosa.

Ahí empiezan los parches. Guardas listas negras, metes jti en base de datos, consultas cache, agregas refresh tokens, rotación y lógica para invalidar pares de tokens. En ese punto ya no tienes un sistema simple sin estado. Tienes un sistema con estado, pero más difícil de razonar.

La guía de OWASP sobre JWT explica varios riesgos de abuso y malas prácticas. No es que JWT sea inseguro por sí mismo; el problema es que mucha gente lo implementa como si fuera una solución mágica y termina exponiendo tokens en lugares inseguros o dejando expiraciones demasiado largas.

Revocar un JWT no es tan directo

Con una sesión tradicional, puedes borrar la sesión del servidor y listo. El siguiente request falla. Con JWT, si el token ya fue emitido y aún no expira, sigue siendo válido a menos que montes una capa adicional de control.

Eso se vuelve especialmente molesto en escenarios como estos:

1. El usuario cambia su contraseña.
2. Un admin bloquea una cuenta comprometida.
3. El usuario pierde el celular y quieres cerrar todos sus accesos.
4. Detectas un token filtrado en logs o en un navegador comprometido.

En todos esos casos, el token firmado no se invalida solo. Necesitas estrategia extra.

Sesiones server-side suelen ser más simples

Con sesiones en servidor, guardas el estado en Redis, base de datos o memoria distribuida. El navegador conserva una cookie segura con un identificador opaco. Si quieres cerrar sesión, borras el estado. Si quieres invalidar todo, eliminas las sesiones activas del usuario.

Eso no significa que siempre debas usar sesiones. Significa que, para muchas apps web, es la opción más simple y robusta. Menos piezas, menos bugs y menos vueltas para resolver algo tan básico como “este usuario sigue autenticado o no”.

Alternativas más sensatas según el caso

No todo es JWT o nada. Hay varias opciones que encajan mejor según tu arquitectura. En muchos proyectos, la mejor respuesta es una cookie segura con sesión server-side. En otros, un token opaco o un flow tipo OAuth 2.0 con un proveedor externo puede ser más apropiado.

Si usas Next.js, Express, Rails, Django o Laravel, no asumas que JWT es la única forma moderna de autenticar. La mayoría de frameworks ya tiene soporte sólido para sesiones, cookies seguras, CSRF protection y middleware de autenticación.

Tabla comparativa rápida

Cuándo elegir cookie segura

Si tu frontend y backend viven bajo el mismo dominio o bajo dominios controlados por ti, una cookie HttpOnly, Secure y SameSite suele ser suficiente. El navegador la envía automáticamente y tú no tienes que exponer un token a JavaScript.

Eso reduce la probabilidad de robo por XSS y simplifica el manejo de sesiones. Además, si necesitas cerrar sesión de inmediato, lo haces desde el servidor sin esperar a que caduque un token firmado.

Cuándo elegir token opaco

Un token opaco es solo un identificador sin claims legibles por el cliente. El backend o un auth server lo resuelve contra una base de datos o cache. Es menos elegante que un JWT, pero mucho más fácil de revocar y auditar.

Para productos que necesitan control fino, listas de acceso, permisos dinámicos o invalidación inmediata, un token opaco puede ser una mejor decisión. No te da la ilusión de autosuficiencia, pero sí te da control real.

Cómo decidir sin caer en dogmas

La decisión correcta depende de tres preguntas simples: ¿necesitas revocación inmediata?, ¿necesitas validación distribuida sin consultar un servidor central?, ¿tu app es web tradicional o una API consumida por muchos clientes? Si respondes con honestidad, la respuesta suele salir sola.

No te conviene usar JWT solo porque “escala mejor”. Primero porque escalar autenticación no suele ser tu cuello de botella al inicio. Segundo porque una mala implementación de JWT puede ser más frágil que una sesión bien hecha con Redis y cookies seguras.

Checklist práctico para elegir

1. Si tu app es un monolito web, empieza con sesiones.
2. Si necesitas cerrar sesiones al instante, evita JWT como sesión principal.
3. Si varios servicios validan identidad localmente, evalúa JWT de corta duración.
4. Si hay login con terceros, usa OAuth 2.0 / OIDC y deja que el proveedor maneje parte del flujo.
5. Si no puedes explicar cómo revocas un token, todavía no lo necesitas.

Señales de que JWT te está complicando

• Tienes blacklists, refresh tokens y rotación para una app simple.
• El equipo no sabe dónde guardar el token en el frontend.
• El logout no invalida accesos previos de forma confiable.
• Cambiar contraseña no corta sesiones activas.
• Tu documentación interna ya necesita un diagrama para explicar autenticación.

Cuando llegas a ese punto, la solución ya dejó de ser simple. Y si tu caso no exige JWT, probablemente estás pagando complejidad sin obtener un beneficio claro.

Implementación mínima si decides no usar JWT

Una sesión server-side no tiene por qué ser complicada. Puedes guardar la sesión en Redis, firmar una cookie y validar el identificador en cada request. Si el usuario hace logout, borras la sesión. Si quieres cerrar todas las sesiones, borras todas las claves asociadas a ese user id.

Ejemplo conceptual en Express con cookie y sesión guardada en servidor:

import express from "express";
import session from "express-session";
import RedisStore from "connect-redis";
import { createClient } from "redis";

const app = express();
const redisClient = createClient({ url: process.env.REDIS_URL });
await redisClient.connect();

app.use(
  session({
    store: new RedisStore({ client: redisClient }),
    secret: process.env.SESSION_SECRET as string,
    resave: false,
    saveUninitialized: false,
    cookie: {
      httpOnly: true,
      secure: true,
      sameSite: "lax",
      maxAge: 1000 * 60 * 60 * 8
    }
  })
);

No es una receta universal, pero muestra la idea: el navegador no guarda credenciales autosuficientes para siempre, sino un identificador de sesión controlado por tu backend.

Si necesitas una referencia sólida sobre cookies seguras, MDN tiene una explicación clara de atributos como HttpOnly, Secure y SameSite: MDN Cookies.

Tabla resumen

JWT no desaparece del mapa, y tampoco debería. Hay arquitecturas donde encaja bien y resuelve un problema real. El punto es dejar de usarlo como reflejo automático y empezar a elegir autenticación según lo que tu producto necesita de verdad.

Si tu app necesita cortar sesiones al instante, manejar estados con claridad y reducir superficie de error, probablemente no necesitas JWT como sesión principal. Si tu caso exige validación distribuida y tokens cortos, entonces sí tiene sentido. La diferencia está en el problema que estás resolviendo, no en la moda del stack.