Decodificador JWT
Pega un token para ver qué contiene y cuándo caduca. Si tienes la clave, también puedes comprobar la firma.
La decodificación se hace en tu navegador. No se envía nada.
Validez
…
Decodificado, no verificado: cualquiera puede crear un token con este contenido. Introduce la clave más abajo para comprobar la firma.
Cabecera
{
"alg": "HS256",
"typ": "JWT"
}Payload
{
"iss": "https://example.com",
"sub": "1234567890",
"aud": "quaestio",
"name": "Ada Lovelace",
"iat": 1757000000,
"nbf": 1757000000,
"exp": 4102444800,
"jti": "4f1c2a9e"
}Campos y claims
- algalgoritmo de firma
- HS256
- typtipo de token
- JWT
- issemisor
- https://example.com
- subsujeto, normalmente el identificador del usuario
- 1234567890
- audaudiencia a la que va destinado el token
- quaestio
- exphora de caducidad
- 4102444800
- nbfno válido antes de
- 1757000000
- iatemitido en
- 1757000000
- jtiidentificador único del token
- 4f1c2a9e
- Firma
- 32 bytes
Verificar la firma
La clave solo se usa en tu navegador y no se guarda.
Cómo funciona
Un JSON Web Token (JWT, RFC 7519) tiene tres partes separadas por puntos: cabecera, payload y firma. La cabecera y el payload son JSON codificado en base64url, una variante de base64 que usa - y _ en lugar de + y / y omite el relleno. Cualquiera puede leer el contenido; no está cifrado.
La cabecera indica el algoritmo (alg) y a menudo el tipo (typ) y el identificador de la clave (kid). El payload contiene claims, afirmaciones sobre el usuario o la sesión. El estándar registra siete: iss (emisor), sub (sujeto), aud (audiencia), exp (caducidad), nbf (no antes de), iat (emitido en) y jti (identificador del JWT). Los demás claims quedan a criterio del emisor.
Las horas de exp, nbf e iat son segundos desde el 1 de enero de 1970 UTC. Un token no debe aceptarse a partir de su hora exp ni antes de su hora nbf. El decodificador las compara con el reloj de tu dispositivo, así que un reloj que va mal da un estado erróneo.
Decodificar no es verificar. La firma demuestra que el token lo emitió alguien que tiene la clave y que el contenido no se ha modificado, pero eso solo se puede comprobar con la clave. HS256, HS384 y HS512 usan un secreto compartido (HMAC). RS y PS usan RSA, ES usa curvas elípticas (ECDSA con P-256, P-384 o P-521) y EdDSA usa Ed25519; estos se comprueban con la clave pública en PEM o JWK, que los emisores suelen publicar como JWK Set.
Un token con alg none no tiene firma y un servidor nunca debe aceptarlo. Varias vulnerabilidades conocidas se debieron a bibliotecas que aceptaban none, o que permitían a un atacante cambiar RS256 por HS256 y firmar con la clave pública como secreto.
Un token suele funcionar como la llave de una cuenta. Aquí todo ocurre en tu navegador con su criptografía integrada (WebCrypto), y ni el token, ni el secreto, ni la clave se envían a ningún sitio. Aun así, nunca pegues un token activo o un secreto en un sitio en el que no confíes, y nunca pegues una clave privada: para verificar solo hace falta la pública.