Anatomía de un JWT: header, payload y signature
Un JWT consiste de tres partes separadas por puntos: header.payload.signature. El header (codificado base64url) declara el algoritmo de firma y tipo de token, típicamente {`{"alg":"HS256","typ":"JWT"}`}. El payload contiene los claims: información sobre el usuario y metadata del token. La signature se genera firmando header+payload con un secreto (HS256) o clave privada (RS256, ES256), garantizando integridad pero no confidencialidad del contenido.
Los claims estándar registrados en RFC 7519 incluyen: iss (issuer), sub (subject - usualmente user ID), aud (audience - quién debe consumir el token), exp (expiration timestamp), nbf (not before), iat (issued at) y jti (JWT ID único para revocación). Estos claims tienen significado universal y deben usarse antes que claims custom para máxima compatibilidad entre librerías.
El payload no es secreto. Está codificado en base64, no encriptado. Cualquiera con acceso al token puede leer su contenido en jwt.io o decodificándolo manualmente. Nunca incluyas passwords, claves privadas, datos médicos o información sensible en el payload. Lo que sí garantiza la firma es que el contenido no fue alterado: si alguien modifica el payload, la signature ya no coincide y el token es rechazado por el validador.
HS256 vs RS256: cuándo usar cada algoritmo
HS256 (HMAC-SHA256) usa un secreto compartido. El mismo string firma y verifica el token. Es ideal cuando quien emite y quien valida es el mismo servicio: una API monolítica firmando sus propios tokens. La ventaja es simplicidad y velocidad. La desventaja: si tres servicios necesitan validar tokens, todos deben tener el secreto, multiplicando el riesgo de filtración. Cualquier servicio comprometido puede falsificar tokens.
RS256 (RSA con SHA-256) usa par de claves: privada para firmar, pública para verificar. El emisor guarda la privada en máxima seguridad. Los validadores solo necesitan la pública (no es secreta). Esto es ideal para arquitecturas microservicios o sistemas federados como OAuth/OIDC: Google emite tokens, mil aplicaciones los validan sin compartir secretos. Las claves públicas se distribuyen via JWKS (JSON Web Key Set) endpoint estándar.
ES256 (ECDSA) es similar a RS256 pero con curvas elípticas. Las firmas son mucho más cortas (64 bytes vs 256+ de RSA), reduciendo el tamaño del JWT. Performance comparable o mejor. La adopción crece pero RS256 sigue siendo más universal. Para producción nueva, ES256 es excelente opción. Para integraciones con sistemas legacy, RS256 garantiza máxima compatibilidad. Nunca uses 'none' como algoritmo: vulnerabilidad histórica explotada en 2015 que sigue apareciendo en CTFs.
Errores de seguridad comunes con JWT
El error más caro es no validar la firma. Algunas librerías permiten decodificar sin validar (función decode vs verify). Si tu código solo decodifica pero no verifica, cualquiera puede inventar un payload, codificarlo en base64 y enviarlo. Tu API lo aceptaría como válido. Siempre usá funciones de verify que validen la signature contra tu secreto o clave pública antes de confiar en el contenido del payload recibido.
Otro error es aceptar el algoritmo del header sin validar. Vulnerabilidad CVE-2015-9235: atacante envía token con alg='none' y muchas librerías lo aceptaban. Variante peor: cambiar HS256 a RS256 usando la clave pública como secreto HMAC. Solución: hardcodeá el algoritmo esperado en tu código de validación. No confíes en el header del token incoming. Si esperás RS256, rechazá explícitamente cualquier otro algoritmo aunque venga firmado correctamente.
El tercer error es tokens de larga duración sin revocación. JWT son stateless: una vez emitidos, valen hasta exp. Si emitís token de 30 días y el usuario cambia password o reporta robo, el token sigue siendo válido. Solución: tokens cortos (15 min) con refresh token de duración larga, blacklist de jti revocados en Redis, o validación contra base de datos de versión de credenciales. Sin estrategia de revocación, JWT pierden ventajas frente a sesiones tradicionales con cookies firmadas.
Casos de uso reales: cuándo SÍ y cuándo NO usar JWT
JWT brilla en autenticación entre servicios. Microservicios que se llaman entre sí pueden firmar requests sin gestionar sesiones compartidas. APIs públicas con OAuth 2.0 usan JWT como access tokens. Single Sign-On (SSO) con OIDC distribuye identity tokens firmados que cada aplicación valida independientemente. Para machine-to-machine, JWT es el estándar de facto en arquitecturas modernas serverless y multi-cloud.
JWT NO es ideal para sesiones de usuario tradicional en monolito. Una cookie de sesión con identificador opaco apuntando a Redis es más simple, permite revocación instantánea y no expone metadata. Si tu app es un Rails o Django monolítico con un servidor, no ganás nada con JWT versus sesión clásica. La complejidad de manejar refresh tokens, revocación y rotación de claves no compensa para casos simples sin dependencias federadas reales.
Otro caso problemático es JWT en cookies con datos sensibles. Si guardás roles y permisos en el token, cada cambio requiere re-emitir el token. Si el admin revoca permisos, el usuario sigue teniendo acceso hasta exp. Para apps con permisos volátiles, mejor consultá la fuente autoritativa (DB) en cada request. El token solo confirma identidad; los permisos se verifican en tiempo real. Esto pierde performance pero gana seguridad y consistencia operativa real.