Decodificar
Verificar
Crear
Probar authz
JWE (cifrado)
SD-JWT
Guía de uso
Qué es un JWT
Un JWT (JSON Web Token) es una credencial compacta y firmada que viaja como una cadena de texto. Se usa sobre todo como token de acceso en APIs, logins y OAuth 2.0 / OpenID Connect: el cliente lo manda en cada petición en la cabecera Authorization: Bearer … y el servidor comprueba la firma para saber quién eres y qué puedes hacer sin consultar una base de datos. La firma garantiza que nadie lo ha manipulado, pero no cifra su contenido: cualquiera puede leerlo (esta misma herramienta lo hace).
Las tres partes
Un JWT tiene tres partes separadas por puntos: header.payload.signature.
• Header (cabecera) — JSON con el algoritmo de firma (alg) y el tipo (typ: JWT); a veces un kid que identifica la clave usada.
• Payload (carga) — JSON con los claims: los datos del token (usuario, permisos, caducidad…).
• Signature (firma) — el resultado de firmar header.payload con el algoritmo del header.
El header y el payload van codificados en Base64URL (no es cifrado, solo texto seguro para URLs). Esta herramienta los decodifica a JSON legible y colorea las tres partes.
Cómo se usa
Dos formas de trabajar:
• Decodificar — pega un token en la pestaña Decodificar y verás al instante el header, el payload y una tabla de claims con su significado y su caducidad. No hace falta la clave para leerlo.
• Crear — en la pestaña Crear escribes el payload (JSON), eliges algoritmo, aportas el secreto o la clave privada y obtienes un token firmado.
El token recién creado lo pasas con un clic a Verificar o al visualizador de flujo de autenticación. Todo ocurre en tu navegador: ni tokens ni claves salen de tu equipo.
Algoritmos de firma (uno a uno)
El campo alg del header dice con qué algoritmo se firmó. Esta herramienta soporta 12, en tres familias; el número es el tamaño del hash SHA (256/384/512).
• HS256 / HS384 / HS512 (HMAC + SHA) — simétricos: la misma clave secreta firma y verifica. Sencillos y rápidos. Úsalos cuando quien firma y quien verifica son la misma parte o comparten el secreto de forma segura (p. ej. un backend que emite y consume sus propios tokens). Inconveniente: cualquiera que pueda verificar también puede falsificar.
• RS256 / RS384 / RS512 (RSA PKCS#1 v1.5 + SHA) — asimétricos: se firma con la clave privada y se verifica con la clave pública. Los más extendidos en OAuth/OIDC: el emisor guarda la privada y publica la pública (JWKS) para que cualquiera verifique sin poder falsificar. Claves grandes (2048 bits) y firma más lenta.
• PS256 / PS384 / PS512 (RSA-PSS + SHA) — RSA asimétrico como RS, pero con relleno PSS (probabilístico), considerado más robusto. Elígelo si tu plataforma lo admite y quieres el RSA moderno.
• ES256 / ES384 / ES512 (ECDSA + curvas P-256/P-384/P-521) — asimétricos de curva elíptica: mismas garantías que RSA pero con claves y firmas mucho más pequeñas y rápidas. Buena opción por defecto para tokens nuevos.
Regla práctica: HS* si compartes un secreto en un entorno controlado; ES* o RS*/PS* si terceros deben verificar sin poder emitir.
Verificar la firma
En Verificar se comprueba la firma de verdad (criptografía Web Crypto del navegador):
• Elige el algoritmo (se preselecciona el que declara el header).
• Si es HS*, pega el secreto. Si es RS/PS/ES*, pega la clave pública en PEM (-----BEGIN PUBLIC KEY-----) o JWK (JSON); la herramienta detecta cuál es.
• Verás Firma válida o inválida, más los chequeos de caducidad (exp) y de «ya válido» (nbf).
Dos protecciones clave: se rechaza siempre alg:none (tokens sin firmar) y se avisa de la confusión de algoritmo — verificar como HMAC un token asimétrico (o al revés) es un fallo de seguridad conocido. La clave nunca sale de tu equipo.
Crear y firmar
En Crear construyes y firmas un token:
• Escribe el payload como JSON; con los chips añades rápido claims estándar (sub, iss, aud, exp…) o comunes (name, role, scope…) con valores de ejemplo.
• Elige el algoritmo y aporta el secreto (HS*) o la clave privada PEM/JWK (RS/PS/ES*). Opcional: un kid en el header.
• Generar claves crea al momento un secreto aleatorio (HMAC) o un par de claves (privada + pública en PEM y JWK) para pruebas.
• Firma y copia el token. Con un clic lo llevas a Verificar (round-trip) o al flujo de autenticación.
JWE: un JWT cifrado
Un JWE (RFC 7516) tiene cinco partes y su contenido va cifrado: sin la clave no se lee. En la pestaña JWE se audita la cabecera sin clave (RSA1_5, roto por oráculos de padding; zip, que deja que el tamaño delate el contenido; PBES2 con pocas iteraciones), se descifra con la clave del destinatario y se cifra para probar. Si dentro va un JWT firmado (cty: JWT), se abre en Decodificar. Descifra con jose, contrastado con los ejemplos de RFC 7516.
SD-JWT: revelar solo lo necesario
Un SD-JWT (RFC 9901, noviembre de 2025; lo usan las carteras de identidad digital europeas) lleva cada dato como el digest de una «disclosure» [sal, nombre, valor], y quien lo presenta enseña solo las que quiere. La pestaña hace lo que un verificador: coloca cada disclosure en su digest, rechaza las que no estaban firmadas, cuenta lo que queda sin revelar, comprueba el Key Binding JWT (su firma con la clave de cnf, nonce, aud y sd_hash) y, si das la clave, la firma del emisor. Contrastado con el ejemplo del propio RFC.
Claims estándar y caducidad
Los claims son los campos del payload. Los registrados (RFC 7519) tienen significado estándar:
• iss — emisor: quién creó el token.
• sub — sujeto: a quién identifica (normalmente el usuario).
• aud — audiencia: para quién es; el receptor debe estar en ella.
• exp — expiración: instante tras el cual deja de valer.
• nbf — no antes de: no vale hasta ese instante.
• iat — emitido en: cuándo se creó.
• jti — ID único: útil para revocación o anti-replay.
Los tiempos van en segundos Unix (segundos desde 1970). La herramienta los muestra como fecha local y en relativo («hace 3 h», «dentro de 42 min») y marca en rojo si el token está caducado (exp pasado) o aún no vale (nbf futuro). Ojo: decodificar no valida — la caducidad solo obliga si el servidor la comprueba al verificar.
Probar authz
La pestaña Probar authz simula la decisión de un gateway o API: defines las reglas que exigirías (emisor, audiencia, scopes/roles) y la herramienta contrasta el token pegado y muestra ALLOW o DENY regla por regla, indicando qué falta o no coincide (incluidas exp y nbf). Sirve para entender por qué un token sería aceptado o rechazado sin montar el backend.
Seguridad
Puntos clave:
• La firma prueba integridad y origen, pero no cifra: el payload es legible por cualquiera. Nunca metas datos sensibles (contraseñas, tarjetas…) en un JWT sin cifrado adicional (JWE).
• Trata los tokens como secretos: no los pegues en sitios públicos ni los guardes en repos. Los ejemplos de aquí usan secretos y claves de juguete; para producción usa claves reales generadas de forma segura y no las pegues en esta herramienta.
• Pon siempre exp (caducidad corta) y verifica en el servidor la firma y el algoritmo esperado. Rechaza alg:none y la confusión de algoritmo.
• Todo el trabajo es local en tu navegador: nada se envía a ningún servidor.
