Back

Decodificador JWT

Los JSON Web Tokens (JWTs) son una forma compacta y segura para URLs de representar declaraciones entre dos partes. La mayoría de los JWTs están firmados usando JWS (Firma Web JSON), que garantiza la integridad pero no cifra el contenido. Esta herramienta decodifica el encabezado y la carga útil para revelar las declaraciones, muestra marcas de tiempo en formato legible y muestra el estado de expiración del token.

Especificaciones

Casos de uso comunes

  • Depurar flujos de autenticación OAuth 2.0 y OpenID Connect
  • Inspeccionar tokens de acceso y tokens de identidad de proveedores de identidad (Auth0, Okta, Keycloak)
  • Verificar que las declaraciones del token coincidan con los valores esperados durante el desarrollo de API
  • Comprobar la expiración del token al solucionar errores "401 Unauthorized"
  • Comprender la estructura del token al integrarse con servicios de terceros
  • Auditar tokens para revisión de seguridad (algoritmo, declaraciones, expiración)

Funcionalidades

  • Decodificar encabezado y carga útil de JWT (formato JWS)
  • Mostrar algoritmo (HS256, RS256, ES256, PS256, EdDSA) y tipo de token
  • Analizar declaraciones registradas: iss (emisor), sub (sujeto), aud (audiencia), exp (expiración), nbf (no antes de), iat (emitido en), jti (ID del JWT)
  • Mostrar estado de expiración con cuenta regresiva legible
  • Copiar secciones decodificadas como JSON formateado

Ejemplos

Token de acceso OAuth 2.0

Pruébalo →

Un token de acceso típico con declaraciones estándar incluyendo sujeto, emisor y expiración.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE5MTYyMzkwMjJ9.4S5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5

Consejos

  • Los tokens JWS (el tipo más común) están firmados pero no cifrados. Cualquiera que tenga el token puede leer la carga útil decodificándola en Base64.
  • Los tokens JWE cifran la carga útil, pero son menos comunes. Esta herramienta decodifica tokens JWS.
  • Siempre verifique las firmas del lado del servidor antes de confiar en las declaraciones. Esta herramienta muestra el contenido decodificado pero no verifica firmas.
  • El algoritmo "alg": "none" es un riesgo de seguridad y debe ser rechazado por los servidores.
  • Los algoritmos simétricos (HS256) usan un secreto compartido; los algoritmos asimétricos (RS256, ES256) usan pares de clave pública/privada.
  • La declaración "exp" es una marca de tiempo Unix en segundos. Verifíquela para evitar aceptar tokens expirados.

Comprender Decodificador JWT

JSON Web Tokens (JWTs) are the dominant token format for modern web authentication and authorization. A JWT is a compact, URL-safe string composed of three Base64url-encoded segments separated by dots: a header specifying the signing algorithm, a payload containing claims about the user or session, and a cryptographic signature that ensures the token has not been tampered with. This structure allows any party to read the token's contents by simple Base64 decoding, while only parties with the signing key can create or verify valid tokens.

Most JWTs use the JWS (JSON Web Signature) format, where the payload is signed but not encrypted. The header's "alg" field specifies the algorithm: symmetric algorithms like HS256 use a shared secret known to both issuer and verifier, while asymmetric algorithms like RS256 and ES256 use a private key for signing and a public key for verification. Asymmetric algorithms are preferred in distributed systems because the verification key can be shared publicly without compromising the signing key.

The payload contains registered claims defined by RFC 7519: "iss" (issuer), "sub" (subject), "aud" (audience), "exp" (expiration time), "nbf" (not before), "iat" (issued at), and "jti" (JWT ID). OAuth 2.0 and OpenID Connect layer additional claims for scopes, roles, and user profile information. The "exp" claim is critical for security — tokens without expiration or with excessively long lifetimes are a common vulnerability.

JWTs are used in OAuth 2.0 access tokens, OpenID Connect ID tokens, API authentication, and session management. Identity providers like Auth0, Okta, and Keycloak issue JWTs that applications verify without contacting the provider, enabling stateless authentication. However, this also means revocation is difficult — a compromised token remains valid until it expires, which is why short expiration times and token refresh flows are essential security practices.

Because JWS tokens are Base64url-encoded rather than encrypted, anyone who possesses the token can decode and read the header and payload. Sensitive information such as passwords, credit card numbers, and secrets should never be placed in a JWT payload. JWE (JSON Web Encryption) tokens do encrypt the payload, but they are far less common in practice. The distinction between encoding and encryption is one of the most important things to understand when working with JWTs.

The choice of signing algorithm has significant security implications. HS256 is a symmetric algorithm that uses a single shared secret for both signing and verification, making it simple to implement but requiring both parties to securely store the same secret. RS256 and ES256 are asymmetric algorithms that use a private key for signing and a public key for verification. In distributed systems, asymmetric algorithms are preferred because the public key can be shared openly — often through a JWKS (JSON Web Key Set) endpoint — without compromising the signing key. The "alg": "none" option signals an unsigned token with no signature at all, meaning anyone can forge tokens with arbitrary claims. A well-known attack involves changing the algorithm header to "none" and stripping the signature. Servers should always validate the algorithm against an allowlist and reject unsigned tokens.

Proper expiration handling is essential for JWT security. Applications should check the "exp" claim on every request before trusting the token. When a token expires, a refresh token (stored securely, often in an httpOnly cookie) can be used to obtain a new access token without requiring the user to log in again. Keeping access token lifetimes short — typically 5 to 15 minutes — limits the window of exposure if a token is compromised. Implementing token refresh proactively, before the access token actually expires, avoids user-facing interruptions in the application.

← Volver a todas las herramientas