Qué hace esta herramienta
Este decodificador de JWT divide un JSON Web Token en sus tres partes — header, payload y firma — y muestra el contenido decodificado junto con los claims registrados (iss, sub, aud, exp, iat, nbf, jti). El periodo de validez se calcula a partir de exp y nbf para que veas de un vistazo si el token está vigente.
También ofrece verificación de la firma para los algoritmos que usan las APIs reales: HS256/384/512 con un secreto compartido, RS256/384/512 y PS256/384/512 con clave pública RSA, ES256/384/512 con clave pública EC y EdDSA con clave Ed25519. Las claves públicas se pueden pegar como JWK, JWKS completo (TaskKit elige la correcta usando el kid del token), bloque PEM SPKI, clave pública PEM PKCS#1 RSA, certificado X.509 (la clave pública se extrae automáticamente) o — para EdDSA — como 64 caracteres hex o 43 base64url. Si el header del token contiene un array x5c (cadena X.509 inline), el certificado hoja se usa automáticamente cuando el campo de clave está vacío.
Cuándo la usarías
- Inspeccionar un token devuelto por tu servidor de auth durante desarrollo local.
- Confirmar que los claims de un token de un tercero coinciden con lo que tu cliente esperaba.
- Verificar que un token renovado está firmado con la misma clave que antes.
- Comprobar la expiración cuando algo dejó de funcionar exactamente a medianoche UTC.
Cómo funciona
La decodificación es solo Base64URL — la spec de JWT usa Base64 URL-safe sin padding. Header y payload son JSON; la firma son bytes crudos. La verificación usa crypto.subtle.verify, la API WebCrypto integrada en el navegador, con el algoritmo extraído del header. EdDSA pasa por @noble/ed25519 (también solo en navegador) ya que el soporte WebCrypto de Ed25519 todavía es irregular entre navegadores.
La entrada de clave es flexible en cuanto a formato. Las claves simétricas (HS*) se importan como bytes crudos o como JWK. Las asimétricas (RS/PS/ES) se aceptan como JWK, JWKS (el kid del token elige la correcta — los conjuntos de una sola clave se usan directamente), PEM SPKI (BEGIN PUBLIC KEY), clave pública PEM PKCS#1 RSA (BEGIN RSA PUBLIC KEY) o certificado X.509 (BEGIN CERTIFICATE) — TaskKit recorre el certificado con un pequeño lector ASN.1 propio para extraer el SubjectPublicKeyInfo embebido. Las claves EdDSA pueden ser JWK, JWKS, SPKI PEM, 64 hex o 43 base64url.
Nada en esta herramienta es del lado del servidor. El token nunca sale de tu navegador, la clave nunca sale de tu navegador y no hay telemetría sobre ninguno. Si pegas un token de producción para depurar algo, tu auditor no verá una petición a taskkit.net cargando ese token.
Notas
¿Por qué se rechaza "alg: none" aunque el token valide? Porque ningún JWT del mundo real debería usar alg: none. Es un vector de ataque conocido: si tu verificador acepta none, un atacante puede quitar la firma y falsificar cualquier payload. Lo marcamos como error en lugar de pasarlo silenciosamente.
¿Qué pasa con kid? Si pegas un JWKS (un objeto con un array keys) y el header del token contiene kid, TaskKit elige la clave cuyo kid coincide. Si no coincide ninguna o no hay kid, falla la verificación con un mensaje explícito en lugar de probar todas las claves a ciegas.
¿Y los certificados X.509? Aceptamos un solo certificado en formato PEM y extraemos el SubjectPublicKeyInfo. La verificación de la cadena (CA, fechas, revocación) está fuera del alcance — eso es trabajo de tu PKI, no de un decodificador.
Herramientas relacionadas
- Codificador JWT — firma tokens localmente con la misma cobertura de algoritmos
- Generador de hashes — para ver SHA-256 y otros
- Base64 — los segmentos de un JWT son base64url; aquí decodificas trozos a mano
- Validador JSON Schema — valida la forma del payload contra un schema