Guía de la herramienta
Acerca de Decodificador y analizador JWT
Un parser JWT decodifica el Header y Payload de un JSON Web Token para inspeccionar alg, typ, estado de firma y claims comunes como iss, sub, aud, iat, nbf y exp.
La herramienta analiza tokens localmente en el navegador y puede re-firmar Header/Payload editados con un secreto HMAC local. El token no se sube a wetool.site.
Cómo usar JWT Parser
- Pega un JWT completo con formato header.payload.signature.
- Pulsa Decode para ver Header, Payload y resumen de claims comunes.
- Revisa exp, nbf e iat; normalmente son segundos Unix.
- Para tokens HMAC de prueba, introduce un secret y la herramienta re-firma localmente el Header/Payload editado.
Cuándo usarlo
- Depurar una sesión de auth comprobando si el token expiró o aún no es válido.
- Confirmar que alg, typ, iss, aud y sub coinciden con el contrato de API gateway o servidor.
- Formatear el payload JSON para encontrar scope, role, tenant_id u otros campos de la app.
- Editar un claim de token de desarrollo y re-firmarlo localmente con un HMAC secret conocido.
Estructura JWT, claims y límites de firma
Un JWT suele tener tres partes Base64URL: Header, Payload y Signature. Decodificar Header/Payload no requiere secret, pero confiar en el token exige verificar la firma con la clave correcta.
- Header: suele contener alg y typ, indicando algoritmo de firma y tipo de token.
- Payload: contiene claims como iss, sub, aud, iat, nbf, exp y campos propios de la app.
- Signature: protege Header/Payload contra cambios; decodificar un token no prueba que la firma sea válida.
- Claims de tiempo: iat, nbf y exp suelen expresarse en segundos Unix, no en milisegundos.
Preguntas frecuentes sobre Analizador JWT
- ¿Decodificar un JWT es lo mismo que verificarlo?
- No. Decodificar solo lee Header y Payload. Verificar requiere comprobar la firma con el secret o public key correcto.
- ¿Por qué puedo leer el payload sin contraseña?
- Header y Payload están codificados en Base64URL, no cifrados. No guardes secretos en un JWT payload normal.
- ¿Qué son exp, iat y nbf?
- exp es la expiración, iat la fecha de emisión y nbf el momento a partir del cual el token es válido. Normalmente se guardan como segundos Unix.
- ¿Un token funciona después de editar el Payload?
- Normalmente no, salvo que se re-firme. Esta herramienta puede re-firmar tokens HMAC de prueba localmente si introduces el secret.
- ¿Mi JWT se sube?
- No. Decodificación, edición y re-firma HMAC se ejecutan localmente en el navegador y no se suben a wetool.site.
JWT vs cookies de sesión
Una sesión suele guardar estado en el servidor y entregar al navegador un session id. Un JWT lleva claims dentro del token, útil entre servicios, pero exige cuidar expiración, claves de firma y contenido del payload.
Checklist de firma JWT y alg
Un JWT decodificable no es automáticamente confiable. La verificación real debe fijar algoritmo, origen de clave, issuer, audience y política de firma.
- No elijas el algoritmo de verificación solo desde el header alg del token; el servidor debe usar una allowlist configurada.
- Trata alg=none, confusión HS256/RS256 o kid que apunta a ubicaciones externas como configuraciones de alto riesgo.
- Esta herramienta sirve para inspección y tokens HMAC de prueba, pero la verificación de producción debe estar en servidor o auth gateway.
Depurar tiempos exp, nbf e iat
Los claims de tiempo de un JWT suelen estar en segundos Unix. Si la expiración parece incorrecta, revisa primero la confusión entre segundos y milisegundos, el desfase de reloj y la zona horaria mostrada.
- Si exp es anterior al epoch actual en segundos, el token expiró; si nbf es posterior a ahora, aún no está activo.
- Interpretar 13 dígitos de milisegundos como segundos produce una fecha muy lejana; interpretar 10 dígitos de segundos como milisegundos cae cerca de 1970.
- Los servidores deben mantener NTP sincronizado y permitir pequeño clock skew, pero no usar largos grace periods para ocultar errores de configuración.