Herramienta de Análisis JWT

JWT (JSON Web Token) es un estándar abierto (RFC 7519) para transmitir información de manera segura entre partes. JWT consta de tres partes separadas por puntos: Encabezado (Header) que contiene el tipo de token y algoritmo de firma, Carga (Payload) que contiene los datos de declaraciones, y Firma (Signature) que verifica la integridad del token. JWT se usa comúnmente para autenticación e intercambio de información. Al trabajar con JWT es importante distinguir decodificar de verificar. El header y el payload solo están codificados en Base64URL, por lo que pueden leerse aunque la firma sea inválida. La confianza aparece con la validación del servidor: firma, algoritmo, expiración, emisor y audiencia. Datos sensibles no deberían colocarse en un payload sin cifrar, porque cualquiera que posea el token puede leerlos. Depurar un token es útil, pero no equivale a aceptarlo.

JWT (JSON Web Token, RFC 7519) se compone de tres partes — Header.Payload.Signature — unidas por el punto inglés '.'. Header: describe el tipo de token y el algoritmo de firma, p. ej. {"alg":"HS256","typ":"JWT"}. alg determina cómo se calcula la Signature; los más comunes son HS256 (HMAC-SHA256), RS256 (RSA-SHA256), ES256 (ECDSA-SHA256) y none (sin firma, prohibido en producción). Payload: también llamado claims, un conjunto de campos JSON. RFC 7519 define 7 claims registrados estándar: iss (emisor), sub (sujeto, normalmente un ID de usuario), aud (audiencia), exp (expiración), nbf (no antes de), iat (emitido en) y jti (ID único). Los desarrolladores pueden añadir cualquier campo privado encima, como userId, role, tenant. Signature: codificar en Base64URL el Header y el Payload, unirlos con un punto y luego firmar con el algoritmo especificado por alg usando una clave. HS256 usa HMAC-SHA256(secret, header_b64 + '.' + payload_b64); RS256 usa una clave privada RSA. El receptor recalcula la firma de la misma manera y comprueba si ambas coinciden. Base64URL frente a Base64 estándar: '+' se convierte en '-', '/' se convierte en '_', y el relleno final '=' se omite, por lo que el resultado puede colocarse en rutas URL y cadenas de consulta sin activar la codificación porcentual. Ten en cuenta que Base64URL es solo una codificación: no proporciona cifrado ni seguridad, y cualquiera puede decodificar y leer el payload. Límite de seguridad: JWT solo garantiza 'no ha sido manipulado', no 'el contenido es sensible'. Un error común es incluir números de teléfono, números de identificación o hashes de contraseñas en el payload, donde todo el mundo puede verlos.

• Estructura de tres partes: Header.Payload.Signature, cada una codificada en Base64URL; la firma es HMAC(secret, header_b64 + '.' + payload_b64) o RSA(privateKey, misma entrada).
• Base64URL intercambia '+' -> '-', '/' -> '_', y omite el relleno final '=', por lo que el resultado codificado puede colocarse directamente en una URL (sin activar codificación porcentual).
• Esta herramienta solo verifica firmas de la familia HMAC (HS256/HS384/HS512) localmente. Algoritmos asimétricos como RS256 o ES256 requieren una clave pública del endpoint JWKS del emisor, así que la verificación de firma debe hacerse en un servidor que tenga la clave pública — la página puede decodificar el header y el payload, pero no puede verificarlos.
• Claims estándar: iss (emisor), sub (sujeto), aud (audiencia), exp (expiración, marca de tiempo Unix en segundos), nbf (no antes de), iat (emitido en), jti (JWT ID, previene reutilización).
• Ataque alg=none: el campo alg debe validarse estrictamente y el algoritmo none debe rechazarse, de lo contrario un atacante puede falsificar cualquier token; también deben prevenirse los ataques de sustitución de algoritmo (verificar un token HS256 usando la clave pública como secreto).
• JWT no está cifrado: el payload es texto plano codificado en Base64URL, no cifrado; para contenido confidencial usar JWE (JSON Web Encryption), pero en la práctica el patrón común es mantener los datos sensibles en el backend y referenciarlos mediante el campo sub.