Um JWT (JSON Web Token) é uma credencial compacta e assinada que viaja como uma cadeia de texto. Usa-se sobretudo como token de acesso em APIs, logins e OAuth 2.0 / OpenID Connect: o cliente envia-o em cada pedido no cabeçalho Authorization: Bearer … e o servidor verifica a assinatura para saber quem és e o que podes fazer sem consultar uma base de dados. A assinatura garante que ninguém o alterou, mas não cifra o seu conteúdo: qualquer um o pode ler (esta mesma ferramenta fá-lo).

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

O campo alg do header indica com que algoritmo foi assinado. Esta ferramenta suporta 12, em três famílias; o número é o tamanho do hash SHA (256/384/512).

• HS256 / HS384 / HS512 (HMAC + SHA) — simétricos: a mesma chave secreta assina e verifica. Simples e rápidos. Usa-os quando quem assina e quem verifica são a mesma parte ou partilham o segredo de forma segura (p. ex. um backend que emite e consome os seus próprios tokens). Desvantagem: quem pode verificar também pode falsificar.
• RS256 / RS384 / RS512 (RSA PKCS#1 v1.5 + SHA) — assimétricos: assina-se com a chave privada e verifica-se com a chave pública. Os mais usados em OAuth/OIDC: o emissor guarda a privada e publica a pública (JWKS) para que qualquer um verifique sem poder falsificar. Chaves grandes (2048 bits) e assinatura mais lenta.
• PS256 / PS384 / PS512 (RSA-PSS + SHA) — RSA assimétrico como RS, mas com preenchimento PSS (probabilístico), considerado mais robusto. Escolhe-o se a tua plataforma o suportar e quiseres o RSA moderno.
• ES256 / ES384 / ES512 (ECDSA + curvas P-256/P-384/P-521) — assimétricos de curva elítica: mesmas garantias que o RSA mas com chaves e assinaturas muito mais pequenas e rápidas. Boa opção por defeito para tokens novos.

Regra prática: HS* se partilhas um segredo num ambiente controlado; ES* ou RS*/PS* se terceiros têm de verificar sem 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.

Os claims são os campos do payload. Os registados (RFC 7519) têm significado padrão:

• iss — emissor: quem criou o token.
• sub — sujeito: quem identifica (normalmente o utilizador).
• aud — audiência: para quem é; o recetor deve estar nela.
• exp — expiração: instante a partir do qual deixa de valer.
• nbf — não antes de: não vale até esse instante.
• iat — emitido em: quando foi criado.
• jti — ID único: útil para revogação ou anti-replay.

Os tempos vêm em segundos Unix (segundos desde 1970). A ferramenta mostra-os como data local e em relativo («há 3 h», «daqui a 42 min») e marca a vermelho se o token estiver expirado (exp passado) ou ainda não válido (nbf futuro). Atenção: descodificar não valida — a expiração só obriga se o servidor a verificar ao validar.

O separador Testar authz simula a decisão de um gateway ou API: defines as regras que exigirias (emissor, audiência, scopes/roles) e a ferramenta compara o token colado e mostra ALLOW ou DENY regra a regra, indicando o que falta ou não coincide (incluindo exp e nbf). Serve para perceber por que um token seria aceite ou rejeitado sem montar o 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).