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 tem três partes separadas por pontos: header.payload.signature.
• Header (cabeçalho) — JSON com o algoritmo de assinatura (alg) e o tipo (typ: JWT); por vezes um kid que identifica a chave usada.
• Payload (carga) — JSON com os claims: os dados do token (utilizador, permissões, expiração…).
• Signature (assinatura) — o resultado de assinar header.payload com o algoritmo do header.
O header e o payload vão codificados em Base64URL (não é cifra, é apenas texto seguro para URLs). Esta ferramenta descodifica-os para JSON legível e colore as três partes.
Duas formas de trabalhar:
• Descodificar — cola um token no separador Descodificar e verás de imediato o header, o payload e uma tabela de claims com o seu significado e a sua expiração. Não é preciso a chave para o ler.
• Criar — no separador Criar escreves o payload (JSON), escolhes o algoritmo, indicas o segredo ou a chave privada e obténs um token assinado.
O token recém-criado passa-lo com um clique para Verificar ou para o visualizador de fluxo de autenticação. Tudo acontece no teu navegador: nem os tokens nem as chaves saem do teu equipamento.
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.
Em Verificar a assinatura é verificada a sério (criptografia Web Crypto do navegador):
• Escolhe o algoritmo (é pré-selecionado o que o header declara).
• Se for HS*, cola o segredo. Se for RS/PS/ES*, cola a chave pública em PEM (-----BEGIN PUBLIC KEY-----) ou JWK (JSON); a ferramenta deteta qual é.
• Verás Assinatura válida ou inválida, mais as verificações de expiração (exp) e de «ainda não válido» (nbf).
Duas proteções chave: alg:none (tokens sem assinatura) é sempre rejeitado, e és avisado da confusão de algoritmo — verificar como HMAC um token assimétrico (ou o contrário) é uma falha de segurança conhecida. A chave nunca sai do teu equipamento.
Em Criar constróis e assinas um token:
• Escreve o payload como JSON; com os chips adicionas rapidamente claims padrão (sub, iss, aud, exp…) ou comuns (name, role, scope…) com valores de exemplo.
• Escolhe o algoritmo e fornece o segredo (HS*) ou a chave privada PEM/JWK (RS/PS/ES*). Opcional: um kid no header.
• Gerar chaves cria na hora um segredo aleatório (HMAC) ou um par de chaves (privada + pública em PEM e JWK) para testes.
• Assina e copia o token. Com um clique levas-lo para Verificar (round-trip) ou para o fluxo de autenticação.
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.
Pontos-chave:
• A assinatura prova integridade e origem, mas não cifra: o payload é legível por qualquer pessoa. Nunca metas dados sensíveis (palavras-passe, cartões…) num JWT sem cifragem adicional (JWE).
• Trata os tokens como segredos: não os coles em sítios públicos nem os guardes em repositórios. Os exemplos aqui usam segredos e chaves de brincar; para produção usa chaves reais geradas de forma segura e não as coles nesta ferramenta.
• Define sempre exp (expiração curta) e verifica no servidor a assinatura e o algoritmo esperado. Rejeita alg:none e a confusão de algoritmo.
• Todo o trabalho é local no teu navegador: nada é enviado para nenhum servidor.