Decodificador JWT

Un JSON Web Token es una cadena compacta formada por tres segmentos separados por puntos (header.payload.signature), cada uno codificado en Base64URL (RFC 4648 sección 5, sin padding): • Header (JOSE Header) — Objeto JSON que declara el tipo de token (typ: "JWT") y el algoritmo de firma (alg). Opcionalmente incluye kid (Key ID) para identificar la clave en un JWKS (JSON Web Key Set), y jku (JWK Set URL) apuntando al endpoint que publica las claves públicas. Ejemplo: {"alg":"RS256","typ":"JWT","kid":"2024-key-1"}. El header se codifica en Base64URL sin padding y forma el primer segmento del token. • Payload (Claims Set) — Objeto JSON con los claims del token. RFC 7519 define siete claims registrados: iss (emisor), sub (sujeto), aud (audiencia), exp (expiración, timestamp Unix), nbf (no válido antes de), iat (momento de emisión) y jti (identificador único del token). Los claims privados contienen datos de la aplicación (roles, permisos, tenant_id). El payload NO está cifrado, solo codificado en Base64URL: cualquier persona con acceso al token puede leer su contenido. Para datos sensibles se usa JWE (JSON Web Encryption, RFC 7516). • Signature — Se calcula sobre la cadena Base64URL(header) + "." + Base64URL(payload) usando el algoritmo declarado en el header. Para HMAC: HMAC-SHA256(secret, input). Para RSA: RSASSA-PKCS1-v1_5-SHA256(privateKey, input). La firma garantiza integridad (el contenido no fue alterado) y autenticidad (fue emitido por quien posee la clave). El servidor receptor verifica la firma usando la clave simétrica (HMAC) o la clave pública (RSA/ECDSA) antes de confiar en los claims.

La elección del algoritmo de firma (claim alg del header) tiene implicaciones directas en la seguridad y la arquitectura del sistema: • HS256 (HMAC-SHA256) — Algoritmo simétrico: la misma clave secreta se usa para firmar y verificar. Ventaja: rápido, simple, sin necesidad de gestión de pares de claves. Desventaja: el secreto debe compartirse entre emisor y todos los verificadores, creando un riesgo de compromiso proporcional al número de servicios que conocen la clave. Adecuado para monolitos o sistemas donde emisor y verificador son el mismo servicio. El secreto debe tener al menos 256 bits de entropía (32 bytes aleatorios); usar passwords cortos o predecibles permite ataques de fuerza bruta offline contra la firma. • RS256 (RSASSA-PKCS1-v1_5 con SHA-256) — Algoritmo asimétrico: se firma con clave privada y se verifica con clave pública. La clave pública se distribuye vía JWKS endpoint (/.well-known/jwks.json). Ideal para microservicios: el servicio de autenticación firma con su clave privada y los demás servicios verifican con la clave pública sin acceso al material sensible. Claves RSA de 2048 bits mínimo (4096 recomendado). PS256 (RSA-PSS) es la variante más segura pero menos compatible. • ES256 (ECDSA con P-256 y SHA-256) — Algoritmo asimétrico basado en curvas elípticas. Firmas y claves significativamente más pequeñas que RSA con seguridad equivalente (256 bits ECC ≈ 3072 bits RSA). Tokens más compactos, ideal cuando el tamaño importa (cookies, headers HTTP). P-256 es la curva estándar; P-384 (ES384) ofrece mayor margen de seguridad. EdDSA con Ed25519 (RFC 8037) es la opción más moderna con mejor rendimiento y resistencia a ataques de canal lateral. • none — Sin firma. Solo debe usarse en entornos de desarrollo local. Los servidores de producción deben rechazar tokens con alg:none explícitamente, ya que un atacante puede modificar el payload y eliminar la firma. Muchas bibliotecas JWT históricamente aceptaban alg:none por defecto, lo que constituye una de las vulnerabilidades más explotadas.

Los JWT implementados incorrectamente son un vector de ataque frecuente en aplicaciones web y APIs: • Ataque alg:none — El atacante modifica el header para declarar "alg":"none", elimina la firma, y envía el token. Si el servidor no valida el algoritmo explícitamente y confía ciegamente en el header, acepta el token sin verificación. Mitigación: el servidor debe rechazar cualquier token cuyo algoritmo no coincida con la lista de algoritmos permitidos (allowlist), sin leer el alg del token para decidir el método de verificación. • Confusión HMAC/RSA — Si un servidor espera RS256, el atacante toma la clave pública RSA (que es conocida), la usa como secreto HMAC, cambia el header a "alg":"HS256" y firma el token. Si la biblioteca JWT despacha el algoritmo basándose en el header del token en lugar de una configuración fija, la verificación HMAC tendrá éxito con la clave pública como secreto. Mitigación: configurar el algoritmo esperado en el servidor, nunca derivarlo del token. • Secretos débiles — Claves HMAC como "secret", "password123" o el nombre de la aplicación permiten ataques de diccionario offline. Herramientas como jwt-cracker y hashcat pueden probar millones de candidatos por segundo contra la firma. Mitigación: usar secretos aleatorios de al menos 256 bits generados con CSPRNG (crypto.randomBytes(32) en Node.js). • Tokens sin expiración — Un JWT sin claim exp o con expiraciones excesivamente largas (meses, años) funciona como una credencial permanente. Si se filtra, el atacante tiene acceso indefinido. Mitigación: exp corto (5-15 minutos para access tokens), refresh tokens con rotación, y un mecanismo de revocación (blacklist en Redis o base de datos) para invalidación inmediata. • Validación incompleta de claims — No verificar aud (audiencia) permite que un token emitido para el servicio A sea aceptado por el servicio B. No verificar iss (emisor) permite tokens de proveedores de identidad no autorizados. Cada servicio debe validar iss, aud, exp, y nbf como mínimo. • JWT vs sesiones — Los JWT son stateless: el servidor no almacena estado de sesión, lo que facilita la escalabilidad horizontal. La desventaja es que la revocación inmediata requiere infraestructura adicional (blacklist). Las sesiones server-side con cookies opacas ofrecen revocación instantanea pero requieren almacenamiento centralizado (Redis, base de datos). La elección depende de los requisitos: microservicios distribuidos favorecen JWT; aplicaciones monoliticas pueden preferir sesiones clásicas.