Decodificador JWT
Los tokens web JSON son tres segmentos Base64url: header.payload.signature. Pegue un JWT para leer el algoritmo (alg), emisor (iss), asunto (sub) y vencimiento (exp) sin enviar el token a un servidor. Este decodificador no verifica las firmas; usa el secreto de su aplicación o JWKS para eso.
JWT token
Output
{
"header": {
"alg": "HS256",
"typ": "JWT"
},
"payload": {
"sub": "1234567890",
"name": "Ada",
"iat": 1516239022
}
}
¿Cómo decodificar un JWT
1. Pegue la cadena JWT (formato eyJ...).
2. Lea el encabezado JSON decodificado (typ, alg).
3. Lea los reclamos de carga útil (sub, exp, roles).
4. Compruebe exp con la hora actual: los tokens vencidos fallan en la autenticación de API.
Ejemplos de inspección de JWT
Depuración 401 no autorizada
Token de acceso de decodificación: exp puede estar en el pasado debido a una desviación del reloj o un TTL corto.
Inspeccionar OAuth id_token
Ver reclamos de nombre y correo electrónico devueltos por el proveedor de identidad.
Revisar el dispositivo de prueba
Confirmar que el token de prueba HS256 tiene la función: reclamo de administrador antes de la prueba de integración.
¿Cuándo decodificar JWTs
• Al depurar la autenticación en desarrollo con tokens de prueba.
• Al aprender la estructura de JWT y los reclamos estándar.
• Al verificar la carga útil antes de implementar RBAC controles.
Límites de seguridad
• No pegue tokens de producción con privilegios activos en sitios web que no sean de confianza; esta herramienta es local, pero tenga cuidado.
• Cuando necesites verificación de firma, use criptografía del lado del servidor con clave secreta/pública.
• Cuando el token esté cifrado JWE, formato diferente al JWS de tres partes.
Reclamaciones registradas estándar
iss (emisor), sub (asunto), aud (audiencia), exp (vencimiento), nbf (no antes), iat (emitido en), jti (ID de JWT). Los reclamos personalizados como roles o inquilino_id son específicos de la aplicación.
Algoritmos de firma
HS256 usa un secreto compartido; RS256 utiliza un par de claves pública/privada RSA. Claves públicas publicadas a través de la URL de JWKS para su verificación.
Desviación del reloj
Las API a menudo permiten un margen de maniobra de 30 a 60 segundos en exp/nbf. Si es válido en el decodificador pero la API lo rechaza, verifique el reloj y la zona horaria del servidor.
Nunca confíe solo en la carga útil
Decodificación del lado del cliente solo para sugerencias de UI: las decisiones de autorización deben verificar la firma en el servidor en cada solicitud.
Preguntas frecuentes
¿Cuáles son? ¿Las tres partes de JWT?
Encabezado (algoritmo y tipo), carga útil (reclamaciones), firma (verificación). Separados por puntos.
¿La decodificación valida el token?
No, cualquiera puede decodificar la carga útil; la firma demuestra integridad y emisor.
¿Qué es el reclamo exp?
Marca de tiempo Unix en segundos cuando el token caduca. Comparar con la hora UTC actual.
¿Ningún ataque de algoritmo?
Los servidores deben rechazar alg:none; el descodificador aún puede mostrar el encabezado para la auditoría.
¿Datos confidenciales en la carga útil?
La carga útil JWT es Base64 no cifrada: nunca coloque contraseñas ni PII innecesariamente.
¿Procesamiento local?
Sí, token analizado en el navegador.
¿Actualizar versus token de acceso?
Ambos son JWT con frecuencia: decodifica cada uno para ver que los alcances y la vida útil difieren.