Entender la estructura de un JWT
Un JSON Web Token (JWT) es un formato de token compacto y seguro para URLs, definido por la RFC 7519. Cada JWT consta de tres partes codificadas en Base64URL separadas por puntos: la cabecera, el payload y la firma. La cabecera declara el algoritmo utilizado para firmar el token (p. ej. HS256, RS256, ES256) y el tipo de token. El payload contiene los claims — declaraciones sobre el sujeto o el propio token.
Los claims registrados estándar incluyen `iss` (emisor), `sub` (sujeto), `aud` (audiencia), `exp` (tiempo de expiración como timestamp Unix), `nbf` (no antes de), `iat` (emitido en) y `jti` (ID del JWT). Los claims privados son cualquier par clave-valor adicional que necesita tu aplicación, como roles de usuario o identificadores de tenant. El decodificador presenta todos los claims en una vista JSON legible junto con los bytes brutos decodificados en Base64URL.
La firma es el tercer segmento. Es calculada por el servidor emisor usando el algoritmo declarado en la cabecera y una clave secreta o privada. La firma garantiza que el token no ha sido alterado en tránsito. Este decodificador muestra los bytes brutos de la firma pero no la verifica — la verificación requiere el secreto del lado servidor o la clave pública.
Leer claims y expiración
El claim `exp` es un valor de fecha numérico que representa los segundos desde la época Unix (1970-01-01T00:00:00Z). Este decodificador lo convierte a una marca de tiempo UTC legible para que puedas ver al instante cuándo expira el token sin aritmética manual. De manera similar, `iat` y `nbf` se renderizan como fechas legibles.
El claim `aud` puede ser una cadena o un array de cadenas que identifica a los destinatarios previstos. Si tu aplicación recibe un token donde `aud` no coincide con el valor esperado, el token debe rechazarse. El decodificador resalta el campo audiencia para que puedas verificarlo rápidamente durante el desarrollo o la depuración.
Muchos proveedores de identidad incorporan claims no estándar: Azure AD incluye `oid`, `tid` y `roles`; Auth0 usa claims con espacio de nombres `https://`; Cognito añade `cognito:groups`. La vista de payload muestra cada claim presente en el token, dándote visibilidad total sobre lo que el proveedor está afirmando sin necesidad de escribir código de decodificación.
Consideraciones de seguridad
Decodificar un JWT no es lo mismo que validarlo. Un token decodificado te muestra los claims, pero no prueba que el token sea auténtico o aún válido. La validación del lado servidor debe verificar la firma contra el secreto o la clave pública, comprobar que `exp` no ha pasado, confirmar que `iss` y `aud` coinciden con los valores esperados, e inspeccionar opcionalmente `nbf`. Nunca confíes en claims de un token no verificado.
Los tokens pueden estar firmados (JWS) o tanto firmados como cifrados (JWE). Este decodificador maneja tokens JWS — la forma más común usada en flujos OAuth 2.0 y OpenID Connect. Si pegas un token JWE (que tiene cinco partes separadas por puntos), el payload será texto cifrado ilegible sin la clave de descifrado.
Evita pegar tokens de producción que contengan datos sensibles de usuarios en herramientas en línea. Este decodificador se ejecuta completamente en tu navegador y no envía ningún dato a ningún servidor, haciéndolo seguro para desarrollo local y depuración. Para credenciales de producción, prefiere herramientas CLI como `jwt-cli` o código de inspección a nivel de biblioteca ejecutándose en tu propio entorno.