¿Cuáles son los errores comunes con JWT — confusión de algoritmo (alg:none), falta de revocación, almacenamiento inseguro?

#Qué es realmente un JWT, y por qué esa forma es peligrosa

Un JSON Web Token son tres segmentos en base64url unidos por puntos: header.payload.signature. El header declara metadatos sobre el propio token — de forma crítica, qué algoritmo se usó para firmarlo (alg). El payload lleva los claims (sub, role, exp, lo que sea que el emisor haya puesto ahí). La firma se calcula sobre el header y el payload usando una clave que controla el servidor. La parte peligrosa es estructural: el header forma parte del token, lo que significa que es entrada controlada por el atacante, exactamente igual que el payload. Todos los errores de JWT? que siguen vienen de código de verificación que confía en algo del header o del payload antes de que la firma se haya comprobado de verdad.

#Error 1: confusión de algoritmo y alg: none

La especificación de JWT define none como un valor de algoritmo legal, que significa "este token no está firmado en absoluto". Existe para casos de uso muy limitados y no productivos, pero si un verificador lee alg del token y despacha su lógica de verificación según ese valor, un atacante puede simplemente reescribir el header a {"alg":"none"}, eliminar la firma por completo y cambiar cualquier claim que le convenga — incluyendo role: "admin".

Una variante más sutil afecta a sistemas que emiten tokens asimétricos (RS256) firmados con una clave privada y verificados con una clave pública. Si el verificador acepta tanto HS256 como RS256 y usa el mismo material de clave para ambos, un atacante puede fabricar un token con alg: "HS256" y firmarlo usando la clave pública de RS256 como secreto HMAC. Las claves públicas, por definición, no son secretas — a menudo se publican en un endpoint /.well-known/jwks.json — así que el atacante termina con un token "firmado" válidamente que el servidor va a aceptar.

// VULNERABLE — confía en el header en vez de fijar el algoritmo
const jwt = require('jsonwebtoken');

function verifyToken(token) {
  const decoded = jwt.decode(token, { complete: true });

  if (decoded.header.alg === 'none') {
    // chequeos "solo para desarrollo local" como este han llegado a producción
    return decoded.payload;
  }

  // Sin lista de algoritmos permitidos: si este mismo servidor también
  // acepta tokens HS256 en otro lugar, un atacante puede firmar con la
  // clave pública de RS256 como secreto HMAC y pasar esta verificación.
  return jwt.verify(token, PUBLIC_KEY);
}

// CORREGIDO — fija el algoritmo explícitamente; nunca confíes en el header,
// nunca llames a decode() cuando el resultado se usará para una decisión de confianza
const jwt = require('jsonwebtoken');

function verifyToken(token) {
  return jwt.verify(token, PUBLIC_KEY, {
    algorithms: ['RS256'],       // rechaza tanto "none" como HS256
    issuer: 'https://auth.example.com',
    audience: 'api.example.com',
    clockTolerance: 5,
  });
  // jwt.verify() lanza una excepción ante firma inválida, algoritmo
  // incorrecto o expiración — trata cualquier excepción como "no autenticado", punto.
}

#Error 2: sin revocación integrada

La gran ventaja de un JWT — no necesitar consultar una base de datos para verificarlo — es también su mayor debilidad operativa. Una vez emitido, un JWT válido sigue siendo válido hasta exp, pase lo que pase después: un cambio de contraseña, una degradación de rol, un baneo de cuenta, un dispositivo robado que se reporta. No existe un DELETE para una firma.

Las mitigaciones prácticas reintroducen, a propósito, una pequeña cantidad de estado:

• Mantener los access tokens de vida corta (5-15 minutos) para que la ventana de exposición ante cualquier problema sea naturalmente pequeña.
• Llevar un jti (JWT ID) o un tokenVersion por usuario en un almacén rápido; incrementarlo al cambiar la contraseña o al cerrar sesión explícitamente, y comprobarlo en cada verificación para las operaciones que de verdad necesitan revocación instantánea.
• Combinar access tokens de vida corta con un refresh token de vida larga rastreado por el servidor — el refresh token es lo que realmente se revoca; al access token simplemente se le deja expirar.

#Error 3: guardar el token de forma insegura en el cliente

Dónde guarda el cliente un JWT determina qué clase de ataque puede robarlo:

• localStorage / sessionStorage — legible por cualquier JavaScript que corra en la página. Un solo bug de XSS en cualquier parte de la app — un script de terceros, un comentario de usuario sin escapar, una dependencia vulnerable — permite a un atacante leer todos los tokens guardados y exfiltrarlos.
• Una variable de JS guardada solo en memoria — se pierde al refrescar, pero es inmune a ser leída por un script ajeno después del hecho (aunque sigue siendo legible mientras un payload de XSS se está ejecutando activamente).
• Una cookie HttpOnly — totalmente invisible para JavaScript, así que un payload de XSS estándar no puede leerla directamente, pero ahora viaja automáticamente en cada request, lo que reabre el CSRF como preocupación salvo que se combine con SameSite y/o un token CSRF.

🧠 Check your understanding
0/3 · 0/3 answered
1. Un verificador de JWT lee el algoritmo a usar desde el propio campo header del token antes de comprobar ninguna firma. ¿Qué ataque habilita esto directamente?
Inyección SQL a través de los claims del payloadUna denegación de servicio mediante tokens sobredimensionadosFuerza bruta lenta del secreto de firmaQue un atacante fabrique un token con alg: none (o un algoritmo distinto al esperado) que evite por completo la verificación de firma
2. ¿Por qué no se puede revocar al instante un JWT comprometido en un diseño puramente sin estado?
Porque los JWT solo se pueden emitir una vez por cuenta de usuarioPorque la verificación de firma tiene éxito independientemente de cualquier estado en la base de datos — no hay nada que borrar en el servidorPorque los JWT nunca expiranPorque la revocación requeriría rotar todo el esquema de la base de datos
3. ¿Cuál es el riesgo principal de guardar un access token JWT en localStorage?
Duplica el tamaño del token en la redEs legible por cualquier JavaScript que corra en la página, así que un solo bug de XSS puede exfiltrarloHace que el token expire más rápidoImpide que el token se envíe por HTTPS