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).

Um JWT é composto por três partes separadas por pontos: header.payload.signature. O header e o payload vão codificados em Base64URL; esta ferramenta descodifica-os para JSON legível.

Cola um token JWT (três partes separadas por pontos) para ver o header, o payload descodificado e os metadados (expiração, iat, etc.).

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.

No separador Verificar verificas a assinatura a sério (HS/RS/ES/PS) fornecendo o segredo (HMAC) ou a chave pública (PEM ou JWK). alg:none é rejeitado e a confusão de algoritmo é assinalada. Tudo acontece no teu navegador: a chave nunca sai do teu equipamento.

Em Criar constróis um JWT a partir de campos e assina-lo (segredo HMAC ou um par de chaves que podes gerar). Em Testar authz defines regras de um gateway (issuer, audiência, scopes/roles) e vês se o token daria ALLOW ou DENY.

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.

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.

A assinatura garante que o token não foi manipulado, mas não cifra o conteúdo: qualquer pessoa pode ler o payload. Nunca incluas dados sensíveis sem cifragem adicional (JWE).