JWT en 2026 — Qué cambió y qué usar en su lugar

JWT sigue siendo la respuesta por defecto cuando alguien dice “auth stateless”, y sigue siendo la opción correcta para algunos trabajos. También sigue siendo equivocada para muchos de los trabajos en los que los equipos lo usan. Este artículo es un status update 2026: qué seguir usando, qué dejar de usar y cuándo saltarse JWT por completo.

Qué te da JWT de verdad

Un JWT son tres segmentos Base64url unidos por puntos: header.payload.signature. El header nombra el algoritmo; el payload son claims JSON; la firma se calcula sobre header.payload usando una clave.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjMiLCJleHAiOjE3MzQ1NjcwMDB9.
_signature_bytes_base64url_

Esa estructura te da exactamente una propiedad: el servidor puede verificar que el payload fue firmado por alguien que tiene la clave, sin consulta a base de datos. Todo lo demás (sesiones, autorización, SSO) está apilado encima de esa primitiva.

Para el detalle de encoding, mira la guía de Base64 en producción — los JWTs usan Base64url sin padding, razón por la que no sobreviven un round-trip por un decoder ingenuo de Base64 estándar.

Las elecciones de algoritmo que sí importan

Alg	Tipo	Clave	Cuándo usar
HS256	HMAC-SHA256	Secreto compartido	Servicio único, o confías totalmente en el verificador
HS384 / HS512	HMAC-SHA384/512	Secreto compartido	Igual que HS256; firmas más grandes rara vez valen la pena
RS256	RSA-SHA256	Par clave pública/privada	Múltiples verificadores (microservicios, SSO)
ES256	ECDSA P-256	Par clave pública/privada	Igual que RS256, firmas más cortas
EdDSA (Ed25519)	Edwards-curve DSA	Par clave pública/privada	Default moderno; rápido, pequeño, sin pifias de RSA
none	Sin firma	Ninguna	Nunca en producción

Tres reglas prácticas para 2026:

1. Usa firmas asimétricas cuando más de un servicio verifica el token. HS256 atrae por ser simple, pero una vez compartes el secreto con tres servicios tienes tres sitios por donde puede filtrarse. RS256 o EdDSA permiten que emisor y verificadores tengan claves distintas.
2. Prefiere EdDSA (Ed25519) para sistemas nuevos. Es más rápido que RSA, las firmas son 64 bytes, y te saltas las trampas de tamaño de clave y modo de padding de RSA. El soporte ya es universal en librerías JOSE.
3. Rechaza alg: none y alg: HS256 en un verificador de clave pública. El ataque clásico de “confusión de alg” es enviar un token firmado con HMAC usando la clave pública RSA del verificador como secreto HMAC. Las librerías modernas rechazan esto por defecto, pero fija el algoritmo esperado explícitamente, no solo “cualquier algoritmo que la librería acepte”.

// Librería jose en Node — fija el algoritmo, no dejes que el token elija
import { jwtVerify, importSPKI } from 'jose';

const publicKey = await importSPKI(pem, 'EdDSA');
const { payload } = await jwtVerify(token, publicKey, {
  issuer: 'https://auth.example.com',
  audience: 'api.example.com',
  algorithms: ['EdDSA'], // allow-list explícita
});

El problema de la revocación

La feature estrella de JWT es “verificación sin estado”: sin consulta a BD. También es su mayor problema operacional. Un token firmado es válido hasta que expira. Si un usuario cierra sesión, o una contraseña se ve comprometida, o se pierde un dispositivo, no puedes invalidar el token instantáneamente sin renunciar al statelessness.

Cuatro respuestas típicas, en orden creciente de coste de infra:

1. Expiración corta + refresh tokens largos. Tokens de acceso viven 5-15 minutos; los refresh viven semanas y viven en una BD donde pueden revocarse. Es el patrón OAuth 2.0 y es el default correcto.
2. Lista de revocación en Redis. Mete los IDs de token (claim jti) de tokens revocados en Redis con un TTL que cuadre con la vida restante del token. El verificador consulta Redis en cada request. Has reintroducido una consulta a BD — pero barata, y solo para tokens revocados.
3. Epoch por usuario. Cada usuario tiene un entero en BD; los tokens llevan el epoch; logout lo incrementa. El verificador compara el epoch del token con el actual del usuario. Una consulta BD por request — mismo coste que consulta de sesión.
4. Renunciar y usar sesiones. En cuanto ya estás haciendo consulta a BD por request, la historia del statelessness desapareció. Tokens aleatorios opacos + una tabla sessions son más simples, más pequeños y más fáciles de revocar.

Cuándo no usar JWT

Checklist corto. Si alguna de estas es cierta, los session tokens opacos en BD probablemente encajan mejor:

• Estás construyendo una webapp estándar con un único backend. No hay federación, ni verificación multi-servicio. Solo necesitas saber quién es el usuario.
• Necesitas logout instantáneo o “matar todas las sesiones” como feature de producto.
• Vas a guardar el token en una cookie igualmente. Las cookies te dan HttpOnly y SameSite; un token aleatorio a secas es más pequeño, más seguro y trivialmente revocable.
• Estabas a punto de meter información personal identificable en el payload porque “el payload está firmado”. Está firmado, no cifrado. Cualquiera con el token lo decodifica.

Session tokens (strings aleatorios opacos) + cookies HttpOnly; Secure; SameSite=Lax + una tabla sessions es aburrido, probado y resuelve el 80% de los casos sin ningún baile de rotación.

Dónde JWT sigue ganando

• Federación y SSO. Los ID tokens de OIDC son JWTs por definición. Si hablas OIDC, hablas JWT.
• Autenticación servicio-a-servicio dentro de una frontera de confianza. JWTs cortos firmados por un único emisor, verificados por muchos servicios, es un patrón limpio.
• Decodificación cliente para hints de UI. Un claim público email en un JWT deja que tu frontend pinte “logged in as X” sin una llamada extra a /me. Recuerda que la firma no protege contra manipulación cliente de la visualización; trátalo como hint, no como fuente de verdad para autorización.

Dos detalles de implementación que la gente olvida

Leeway en exp y nbf. Los relojes derivan. Toda librería JOSE te deja configurar una ventana de tolerancia (default 0-30s). Pónlo a algo; no despliegues un verificador que rechaza tokens por 2s de skew entre tus propios data centers.

Rota claves. Las claves asimétricas deben rotarse por calendario (90-365 días es típico). Publica la clave pública actual y la anterior para que tokens firmados bajo la clave vieja sigan validando durante el rollover. JWK Sets (JWKS) gestiona esto; si verificas a mano, acabarás acorralándote.

Para la visión general de cómo UUIDs y tokens difieren como identificadores opacos, mira la pieza UUID v4 vs v7; para las elecciones de hash y password-hashing que anclan el flujo de auth, mira la comparativa de funciones hash.

Conclusiones

Usa JWT cuando necesites verificación cross-servicio o cross-party sin BD compartida. Usa session tokens opacos para el caso mono-app. Fija el algoritmo, prefiere EdDSA para sistemas nuevos, nunca metas secretos en el payload, y planea la revocación antes de necesitarla.