RevealTheme logo

Decodificador de JWT

Decodifique JSON Web Tokens (JWT) instantaneamente. Executa no seu navegador: os tokens nunca saem do seu dispositivo, por isso é seguro usá-lo com segredos de produção.

Como usar esta ferramenta

  1. 1

    Cole seu JWT no campo de entrada.

  2. 2

    Clique em Decodificar. O cabeçalho e a carga útil são analisados e exibidos.

  3. 3

    Inspecione o algoritmo, as claims, a expiração e o emissor.

O que é um JWT e como ele funciona?

Um JSON Web Token (JWT, definido na RFC 7519) é uma forma compacta e segura para URL de representar um conjunto de claims sobre um usuário, com prova criptográfica de que essas claims não foram adulteradas. Os JWT impulsionam a autenticação na maioria das stacks web modernas: quando você faz login, o servidor cria um JWT que contém o seu ID de usuário e as suas permissões, assina-o com uma chave secreta e o devolve para você. O seu navegador armazena o token (normalmente em localStorage ou em um cookie) e o inclui no cabeçalho Authorization de cada solicitação posterior. O servidor verifica a assinatura em cada solicitação: se for válida, confia-se nas claims do token; se ele foi adulterado, a assinatura quebra e a solicitação é rejeitada. Os JWT têm três partes codificadas em Base64URL e separadas por pontos: o cabeçalho declara o algoritmo de assinatura (HS256 para HMAC-SHA256, RS256 para RSA, ES256 para ECDSA, none para tokens sem assinatura, o que é perigoso e você deveria rejeitá-los); o payload contém as claims propriamente ditas (claims padrão como 'sub' para o sujeito, 'exp' para a expiração, 'iat' para a data de emissão, além de qualquer claim personalizada que o seu aplicativo defina); a assinatura é a prova de que o cabeçalho e o payload foram assinados por alguém que possuía o segredo. Este decodificador revela as duas primeiras partes, que são informação pública; a assinatura só pode ser verificada com a chave, razão pela qual todo decodificador de JWT exibe as claims sem verificação.

Casos de uso comuns

  • Depure problemas de autenticação decodificando o JWT que seu cliente está enviando: veja exatamente quais claims estão presentes, quem o emitiu e quando ele expira.

  • Inspecione os JWTs de gateways de API (AWS Cognito, Auth0, Okta) para entender a estrutura das claims dos serviços posteriores.

  • Verifique se as claims personalizadas (ID da organização, função, feature flags) estão sendo definidas corretamente no código que emite o token.

  • Compare tokens antes e depois de uma renovação para confirmar que a expiração foi estendida.

  • Audite o algoritmo de um token: confirme que RS256 ou ES256 é usado em produção, nunca 'none'.

  • Traduza cargas úteis em base64url dos logs do servidor para claims legíveis.

Perguntas frequentes

É seguro usá-lo com JWT de produção?
Sim. A decodificação ocorre inteiramente no seu navegador por meio de JavaScript local: o token nunca chega aos nossos servidores nem aparece em nenhum log. Você pode comprovar isso abrindo o DevTools → aba Rede enquanto decodifica: nenhuma solicitação de saída é disparada. Dito isso, trate os JWT como credenciais: não os cole em URLs, capturas de tela ou documentos compartilhados, não importa onde o decodificador seja executado.
Isto verifica a assinatura?
Não. A verificação da assinatura requer o segredo (para HS256) ou a chave pública (para RS256/ES256/PS256). As ferramentas web que pedem o seu segredo para verificar um JWT são um sinal de alerta de segurança: você estaria enviando a sua chave de assinatura para um desconhecido. Verifique as assinaturas no servidor ou com uma biblioteca que você controle (jose, jsonwebtoken).
O que acontece se o meu JWT tiver expirado?
A expiração não impede a decodificação: a claim 'exp' é apenas um dado dentro do payload. Procure 'exp' no payload decodificado: é um timestamp Unix (segundos desde 1970). Converta-o com o nosso Conversor de Timestamp para ver a expiração no seu fuso horário. Se 'exp' já passou, o token é rejeitado por qualquer verificador em conformidade, ainda que o decodificador continue a lê-lo.
Os JWT podem ser criptografados?
Sim: isso se chama JWE (JSON Web Encryption, RFC 7516). Esta ferramenta lida com JWS (JSON Web Signature, o caso comum), em que o payload está assinado mas é visível. Os tokens JWE têm 5 partes separadas por pontos em vez de 3 e exigem a chave privada do destinatário para serem descriptografados. Se o seu token tiver 5 partes, você precisa de uma ferramenta compatível com JWE.
O que significa 'alg': 'none' e isso é perigoso?
'none' significa que não há assinatura: o token está sem assinatura e qualquer pessoa pode forjar qualquer claim. Os sistemas de produção devem rejeitar explicitamente os tokens com 'alg: none'. Algumas bibliotecas os aceitam por padrão (uma classe de CVE bastante conhecida). Permita sempre apenas os algoritmos que o seu aplicativo espera.
Por que usar JWT em vez de cookies de sessão?
Os JWT não têm estado: o servidor não precisa consultar uma sessão; o próprio token contém a identidade e as permissões do usuário. Isso torna os JWT ideais para sistemas distribuídos e APIs. Os cookies de sessão têm estado (exigem armazenamento de sessão no servidor) mas são mais fáceis de invalidar (basta apagar a sessão). O trade-off: os JWT escalam melhor, mas você não pode 'desconectar um usuário' até que o token expire.
Quais são as claims padrão de um JWT?
A RFC 7519 define: iss (emissor), sub (sujeito, normalmente o ID de usuário), aud (audiência), exp (hora de expiração), nbf (não antes de), iat (emitido em), jti (ID do JWT). Além dessas, os aplicativos adicionam claims personalizadas como 'roles', 'permissions' ou 'tenant_id'. Mantenha as claims personalizadas pequenas: os JWT viajam no cabeçalho de cada solicitação e aumentam o seu consumo de banda.

Ferramentas relacionadas