Decodificador e Inspector JWT
Decodifique e inspeccione JSON Web Tokens (RFC 7519) en su navegador. Analice parámetros de cabecera Base64URL, declaraciones del payload, marcas de tiempo Unix de expiración y verifique firmas HMAC, RSA o ECDSA localmente con cero transmisión al servidor.
HEADER (Algoritmo y tipo de token)
{
"alg": "HS256",
"typ": "JWT"
}PAYLOAD (Datos y declaraciones)
Tue, 01 Jan 2030 00:00:00 GMT
Hora local: 1/1/2030, 0:00:00
Wed, 01 Jan 2025 00:00:00 GMT
Hora local: 1/1/2025, 0:00:00
VERIFICAR FIRMA (Web Crypto API local en navegador)
Algoritmo: HS256Flujo de Inspección y Análisis de JWT Paso a Paso
- Pegue la cadena JWT codificada en el panel de entrada o pulse uno de los ejemplos predefinidos (HS256 Activo, Token Expirado o RS256 OIDC).
- Inspeccione el panel Header para verificar el algoritmo criptográfico (alg), el tipo de token (typ) y el identificador de clave (kid).
- Examine el panel Payload para analizar las declaraciones de identidad estándar (sub, iss, aud) y los metadatos propios de la aplicación.
- Consulte el Inspector de Marcas de Tiempo y Declaraciones para revisar las conversiones a fecha UTC y local de exp (Expiración), iat (Emisión) y nbf (Inicio de validez).
- De forma opcional, introduzca su clave secreta HMAC o clave pública RSA/ECDSA en formato PEM para verificar la integridad criptográfica localmente mediante la Web Crypto API.
Anatomía de la Serialización Compacta de JWT (RFC 7519 y RFC 7515)
Un JSON Web Token en formato compacto se serializa como tres segmentos independientes codificados en Base64URL, concatenados mediante delimitadores de punto (.):
Especifica los metadatos del token: el algoritmo criptográfico de firma (alg, como HS256 o RS256), el tipo de token (typ: "JWT") y el identificador opcional de clave (kid).
Contiene afirmaciones sobre la entidad autenticada y metadatos de sesión. Codifica marcas de tiempo registradas (exp, iat, nbf), emisor (iss), audiencia (aud) y declaraciones personalizadas.
Se calcula aplicando la función criptográfica especificada sobre ProtectedHeader.Payload empleando la clave secreta o privada. Permite al receptor verificar matemáticamente la integridad de los datos.
Especificación de Codificación: Base64 Estándar frente a Base64URL
El RFC 7519 exige la codificación Base64URL (RFC 4648 §5) en lugar de Base64 estándar (RFC 4648 §4) para garantizar que los tokens viajen de manera segura en cabeceras HTTP Authorization, parámetros de consulta y cookies sin necesidad de codificación porcentual:
| Parámetro de Codificación | Base64 Estándar (RFC 4648 §4) | Base64URL (RFC 4648 §5 / RFC 7519) | Justificación de Ingeniería en JWT |
|---|---|---|---|
| Carácter 62 | + (signo más) | - (signo menos / guion) | Elimina conflictos en URLs donde + representa un espacio en blanco codificado |
| Carácter 63 | / (barra diagonal) | _ (guion bajo) | Evita colisiones con delimitadores de ruta y errores de enrutamiento en servidores web |
| Carácter de Relleno | = (signo igual) | Omitido (sin relleno) | Previene colisiones con delimitadores clave-valor; la cantidad de relleno se deriva como (4 - (len % 4)) % 4 |
| Seguridad en Transporte | Requiere codificación porcentual de URL | Seguro en cabeceras, URLs y cookies | Garantiza cero mutación al transmitirse en cabeceras Authorization: Bearer <token> |
Ciclo de Vida de Declaraciones Registradas y Validación en Pasarelas (RFC 7519 §4.1)
El RFC 7519 define siete nombres de declaraciones registradas estándar para facilitar la interoperabilidad entre proveedores de identidad y servidores de recursos:
| Declaración | Nombre Formal | Tipo | Condición de Validación | Acción del Verificador / Pasarela |
|---|---|---|---|---|
| exp | Expiration Time | NumericDate | horaActual < exp + margen | Rechazo obligatorio con 401 Unauthorized si la marca Unix actual supera el valor de expiración |
| nbf | Not Before | NumericDate | horaActual >= nbf - margen | Rechaza peticiones recibidas antes de la hora programada de activación; usado en tokens preemitidos |
| iat | Issued At | NumericDate | iat <= horaActual + margen | Aplica antigüedad máxima del token y detecta tokens con fechas futuras provocados por desincronización de reloj |
| iss | Issuer | StringOrURI | iss === emisorEsperado | Comprobación estricta de igualdad de cadena frente a la URL de autoridad del emisor (ej. https://auth.ejemplo.com) |
| aud | Audience | String | Array | aud.includes(audienciaDestino) | Rechaza el token si el identificador de la API receptora no figura en la lista; evita escaladas entre servicios |
| sub | Subject | String | sub !== vacío | Identificador único del sujeto principal (UUID de usuario, cuenta de servicio) dentro del ámbito del emisor |
| jti | JWT ID | String | !cacheRedis.has(jti) | Identificador único (nonce) verificado contra una caché distribuida para garantizar tokens de un solo uso y evitar ataques de reproducción |
Configuración de Deriva de Reloj y Margen de Tolerancia (Clock Skew)
En arquitecturas distribuidas, los servidores de autorización y las pasarelas de API experimentan ligeras discrepancias horarias debido a los intervalos de sincronización NTP. Los motores de verificación en producción (como Envoy clock_skew_seconds o Node.js clockTolerance) recomiendan configurar una tolerancia de 30 a 60 segundos. Sin este margen, un token emitido milisegundos antes en un servidor adelantado sería rechazado de inmediato por una pasarela con reloj ligeramente retrasado.
Comparativa de Algoritmos Criptográficos de Firma (RFC 7518 JWA)
El RFC 7518 categoriza los algoritmos de firma digital entre esquemas simétricos basados en clave secreta compartida y criptosistemas asimétricos de clave pública:
| Algoritmo | Familia Criptográfica | Arquitectura de Claves | Tamaño de Firma | Latencia de Verificación | Compromisos Arquitectónicos |
|---|---|---|---|---|---|
| HS256 | HMAC con SHA-256 | Clave secreta simétrica compartida (≥256 bits) | 32 bytes | ~10 µs | Máxima velocidad; requiere distribuir el secreto a cada verificador, lo que incrementa el riesgo de exposición multiservicio |
| RS256 | RSASSA-PKCS1-v1_5 con SHA-256 | Asimétrico RSA (par de claves de 2048/4096 bits) | 256 bytes | ~200 µs | Estándar OIDC; las claves públicas se distribuyen de forma segura mediante extremos JWKS; mayor consumo de CPU en verificación |
| ES256 | ECDSA con NIST P-256 y SHA-256 | Asimétrico por Curva Elíptica | 64 bytes | ~60 µs | Tamaño de firma compacto; robustez criptográfica equivalente a RSA de 3072 bits con un 75% menos de sobrecarga en transporte |
| EdDSA | Curva Edwards Ed25519 | Asimétrico Curva Edwards Retorcida | 64 bytes | ~25 µs | Ejecución en tiempo constante inmune a ataques de temporización por canal lateral; estándar moderno para proxies edge de alto rendimiento |
Guía de Diagnóstico y Resolución de Incidencias en Pasarelas de Producción
Referencia diagnóstica para la resolución sistemática de fallos de autenticación frecuentes en proxies edge, API gateways y microservicios:
| Error de Pasarela | Identificación de Causa Raíz | Paso de Verificación Técnica | Mitigación de Ingeniería |
|---|---|---|---|
| 401 token_expired | La marca de tiempo exp del token está en el pasado, o el reloj de la pasarela está adelantado respecto al emisor. | Compare la marca Unix exp con el reloj de la pasarela mediante el comando date +%s. | Sincronice los servidores vía NTP; implemente rotación silenciosa de tokens en el cliente en exp - 30s. |
| 401 invalid_signature | Discrepancia en el secreto de firma, formato PEM defectuoso o secreto Base64 interpretado como texto sin formato. | Compruebe si el servidor importó el secreto como cadena UTF-8 cruda o como array de bytes decodificado de Base64. | Asegúrese de que la codificación del secreto coincida exactamente; elimine saltos de línea finales accidentales (\n) en las variables de entorno. |
| 403 audience_mismatch | El identificador de recurso de la pasarela no figura en la declaración aud del payload. | Examine la declaración aud decodificada; confirme que contiene el URI de la API destino. | Configure el parámetro audience en el servidor de autorización OAuth 2.0 durante el intercambio del código de autorización. |
| 431 header_too_large | El JWT excede el límite de cabeceras del proxy (habitualmente 8 KB en Nginx/Envoy o 4 KB en cookies). | Revise el tamaño en bytes del token completo; detecte matrices sobredimensionadas de permisos o grupos anidados. | Descargue los grupos masivos del payload trasladándolos a un extremo de información de usuario (userinfo) o almacén de sesiones. |
Vulnerabilidades Críticas de Seguridad y Mitigaciones Técnicas
El Exploit "alg: none"
Las bibliotecas vulnerables que confían ciegamente en el parámetro alg de la cabecera omiten la verificación de firma si un atacante manipula la cabecera a {"alg": "none"} y descarta el segmento de firma. En entornos de producción, fije siempre de forma estricta los algoritmos permitidos (ej. algorithms: ['RS256']) y rechace sistemáticamente cualquier token sin firma.
Confusión de Claves (CVE-2015-9235)
Cuando un backend configurado para RS256 procesa un token en el que un atacante alteró alg a HS256, un verificador descuidado puede usar la clave pública RSA disponible públicamente como secreto simétrico HMAC. La verificación tiene éxito porque ambas partes poseen dicha clave pública. Mitigue esto comprobando que el tipo de clave coincida estrictamente con la familia de algoritmos prevista antes de invocar la verificación.
Riesgo de Exposición en Texto Claro (JWS frente a JWE)
Un token compacto estándar JWT está firmado (JWS), no cifrado (JWE). La codificación Base64URL es trivial de revertir sin disponer de claves criptográficas. Nunca almacene credenciales en texto plano, datos de tarjetas de pago, información personal identificable (PII) ni cadenas de conexión a bases de datos en las declaraciones de un JWT no cifrado.
Limitación de Revocación sin Estado (Stateless Revocation)
Dado que los tokens JWT son entidades sin estado, un token emitido no puede revocarse de manera nativa hasta que transcurra su tiempo exp. La mitigación en producción requiere emitir tokens de acceso de corta duración (5 a 15 minutos) acompañados de tokens de actualización (refresh tokens) con estado almacenados en cookies HttpOnly, o mantener listas de bloqueo distribuidas en Redis para las declaraciones jti revocadas.
Frequently Asked Questions
¿Puede cualquier persona decodificar y leer un JWT sin conocer la clave secreta?
Sí. Un JSON Web Token estándar (RFC 7519) es un formato con firma digital (JWS), no cifrado (JWE). La cabecera (Header) y la carga útil (Payload) son cadenas JSON serializadas mediante codificación Base64URL. Cualquier entidad que intercepte o posea el token puede decodificarlo y leer todas las declaraciones contenidas sin necesidad de una clave secreta. Las claves secretas compartidas o los pares de claves pública y privada únicamente se requieren para generar o verificar criptográficamente la firma digital, no para inspeccionar los datos del payload.
¿Es seguro pegar tokens JWT de entornos de producción en este decodificador online?
Totalmente seguro. Esta herramienta opera al 100% en el entorno cliente dentro de su navegador web. El análisis del token, el formateo de marcas de tiempo y la verificación criptográfica de firmas (mediante la API nativa Web Cryptography crypto.subtle) se ejecutan exclusivamente en la memoria local. Ninguna cadena de token, cabecera de autorización, clave secreta HMAC o clave pública PEM se transmite a través de la red, ni se almacena o registra en servidor alguno.
¿Cuál es la diferencia técnica entre decodificar un JWT y verificar su firma digital?
La decodificación es una deserialización no autenticada: revierte la codificación Base64URL de los segmentos de cabecera y carga útil para que pueda inspeccionar declaraciones, algoritmos y marcas de tiempo. La verificación es una operación criptográfica estricta: recalcula la firma digital sobre cabecera.payload empleando una clave secreta HMAC o comprueba una firma asimétrica frente a una clave pública RSA/ECDSA para demostrar matemáticamente que el token procede de un emisor de confianza y no fue alterado durante el tránsito.
¿Cómo se comprueba si un JWT ha expirado a partir de sus declaraciones?
Se inspecciona la declaración registrada estándar "exp" (Expiration Time) en la carga útil. Contiene una marca de tiempo Unix NumericDate (segundos transcurridos desde el 1 de enero de 1970 UTC). Si la marca de tiempo actual (Math.floor(Date.now() / 1000)) supera el valor de exp, el token se considera expirado. Esta herramienta convierte automáticamente exp a formatos UTC y local, calculando la vida útil remanente con cuenta regresiva en tiempo real. En pasarelas de producción, suele añadirse un margen de tolerancia (clock skew leeway) de 30 a 60 segundos.
¿Por qué los decodificadores estándar de Base64 fallan o corrompen las cadenas JWT?
El estándar JWT impone la codificación Base64URL (RFC 4648 §5) en lugar de Base64 estándar (RFC 4648 §4). Base64URL sustituye "+" por "-", "/" por "_", y elimina todos los caracteres de relleno "=" finales para que el token viaje de forma segura en cabeceras HTTP, cookies y parámetros URL sin necesidad de codificación porcentual. Funciones estándar como window.atob() fallan a menos que se restablezcan los caracteres "-" y "_" a "+" y "/" y se recalcule el relleno "=" mediante la fórmula (4 - (len % 4)) % 4.
¿Por qué aparece un error de formato no válido (Invalid Token o Malformed JWT)?
Un JWT compacto válido exige estrictamente tres segmentos separados por puntos (cabecera.payload.firma). Los fallos de análisis más comunes son: (1) incluir por error el prefijo "Bearer " de una cabecera HTTP Authorization; (2) copiar espacios en blanco o saltos de línea accidentales; (3) introducir un token cifrado JWE (que consta de cinco segmentos separados por puntos); o (4) caracteres Base64URL corruptos o JSON con sintaxis errónea en la carga útil.
¿Cómo verificar un token RS256 o ES256 si el proveedor de identidad solo ofrece un extremo JWKS?
Los proveedores de identidad (como Auth0, Okta, Keycloak, AWS Cognito o Azure AD) publican sus claves públicas en un conjunto JSON Web Key Set en /.well-known/jwks.json. Para verificar localmente: (1) localice el objeto de clave cuyo "kid" coincida con el "kid" de la cabecera del token; (2) extraiga el módulo "n" y el exponente "e" de RSA (o las coordenadas "x" e "y" en EC); (3) conviértalos a formato PEM (mediante utilidades como OpenSSL o bibliotecas jwk-to-pem); y (4) pegue la clave pública PEM resultante en el campo de verificación de esta herramienta.