JWT (JSON Web Token) es un estándar abierto definido por el IETF en RFC 7519 (RFC 7515 describe la forma de firma JWS, RFC 7516 describe el cifrado JWE, RFC 7517 define las claves JWK) para transferir de forma segura información de usuario 'afirmada' entre solicitudes HTTP, flujos OIDC y llamadas de microservicios. Una cadena JWT estándar se compone de tres segmentos codificados en Base64URL: Header (algoritmo y tipo), Payload (Claims, los datos del usuario) y Signature (una firma basada en clave sobre los dos primeros). Los tres segmentos se unen con un punto literal `.`, por ejemplo `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.
**JWT no es cifrado.** Este es el concepto erróneo más común. El Payload es texto plano por defecto — cualquiera puede decodificarlo con Base64URL y leer el contenido. JWT proporciona **detección de manipulación**, no confidencialidad: el servidor vuelve a firmar Header.Payload con la clave compartida y la compara con la Signature del token. Si coinciden, el token no ha sido alterado en tránsito. Esta es la metáfora del 'boleto de tren con un sello antifalsificación': al inspector le importa si el boleto es genuino, no si el código QR es ilegible.
JWT divide claramente las responsabilidades entre 13 algoritmos. **Familia HMAC** (HS256/HS384/HS512) usa una clave simétrica tanto para firmar como para verificar, rápida y simple, adecuada para un solo servicio o un clúster de confianza; el secret debe tener al menos la longitud del digest (por ejemplo, ≥ 32 bytes para HS256). **Familia RSA** (RS256/RS384/RS512) usa RSASSA-PKCS1-v1_5, el esquema asimétrico más común — los firmantes tienen la clave privada, los verificadores tienen la clave pública. **Familia RSA-PSS** (PS256/PS384/PS512) usa el relleno RSA-PSS más nuevo con garantías de seguridad más fuertes, preferido por AWS SigV4 y proveedores de identidad OIDC modernos. **Familia ECDSA** (ES256/ES384/ES512) usa curvas elípticas (P-256/P-384/P-521 respectivamente) con firmas más cortas y mejor rendimiento. **EdDSA** (principalmente Ed25519) es extremadamente rápido y determinista (mismo mensaje + misma clave = misma firma cada vez) y es el algoritmo recomendado en OAuth 2.1 y nuevos protocolos.
La seguridad es donde JWT tropieza en producción. La OWASP JWT Cheat Sheet destaca al menos cuatro reglas estrictas: (1) nunca pongas contraseñas, documentos de identidad, números de tarjetas o claves API como texto plano en el Payload; (2) el servidor **nunca debe confiar en el campo alg** declarado en el Header del Token — debe verificar con un algoritmo codificado, de lo contrario un atacante que reescriba el header a `alg: none` lo evade todo (esta es la raíz de CVEs históricos como CVE-2015-9235); (3) los secrets HMAC deben ser aleatorios y tener al menos 32 bytes, nunca cadenas cortas; (4) la verificación es más que verificar firmas — también debes validar `exp` (expiración), `nbf` (no antes), `iss` (emisor) y `aud` (audiencia). Esta herramienta resalta cada uno de estos Claims en la interfaz para que puedas decir de un vistazo si un fallo es un problema de firma, un problema de tiempo o un problema de Claims.
JWT no es un reemplazo para las sesiones. Las sesiones almacenan el estado del usuario en el servidor (Redis o una base de datos); JWT empaqueta el estado en el token. Las arquitecturas de microservicios, las API sin estado, los clientes móviles y las configuraciones con mucho CORS se benefician de JWT; los sistemas empresariales tradicionales y los flujos que requieren revocación instantánea (por ejemplo, 'expulsar a este usuario ahora') siguen siendo mejor atendidos por sesiones. Esta herramienta cubre tanto la depuración pura de JWT como los pasos de análisis de Token / verificación de firma / edición de Payload de una migración de sesión a JWT.