Ferramenta de Análise JWT
Decodifique e verifique JSON Web Token, visualize Header, Payload e Signature
JWT de Exemplo
O que é JWT?
JWT (JSON Web Token) é um padrão aberto (RFC 7519) para transmitir informações de forma segura entre partes. JWT é composto por três partes separadas por pontos: Header contém o tipo do token e o algoritmo de assinatura, Payload contém os dados de claims, e Signature é usada para verificar a integridade do token. JWT é amplamente utilizado para autenticação e troca de informações. Ao trabalhar com JWTs, é importante distinguir decodificação de verificação. Header e payload são apenas codificados em Base64URL, então podem ser lidos mesmo quando a assinatura é inválida. A confiança vem da validação no servidor: assinatura, algoritmo, expiração, emissor e audiência. Dados sensíveis não devem ficar em payload sem criptografia, porque qualquer pessoa com o token pode lê-los. Depurar um token é útil, mas não é o mesmo que aceitá-lo.
Como Usar
Como usar
- Cole um JWT na caixa de entrada e a ferramenta analisará e exibirá automaticamente o conteúdo do cabeçalho e do payload
- Clique nas tags coloridas para copiar a parte correspondente codificada em Base64
- Insira o segredo na área de verificação de assinatura para verificar se a assinatura está correta (suporta os algoritmos HS256/HS384/HS512)
- A área de informações-chave exibe os valores decodificados das claims comuns, e o status de expiração é indicado por cores
Dicas de Segurança
- Esta ferramenta é executada localmente no seu navegador; o Token nunca é enviado a nenhum servidor
- O JWT apenas codifica e assina dados, não é criptografado; qualquer pessoa pode decodificar e visualizar o conteúdo
- Não armazene informações sensíveis no JWT (como senhas, números de cartão de crédito, etc.)
- Sempre use HTTPS para transmitir JWT em ambientes de produção
Casos de uso
Princípio técnico
JWT (JSON Web Token, RFC 7519) é composto por três partes — Header.Payload.Signature — unidas pelo ponto em inglês '.'. Header: descreve o tipo do token e o algoritmo de assinatura, ex. {"alg":"HS256","typ":"JWT"}. alg decide como a Signature é calculada; os mais comuns são HS256 (HMAC-SHA256), RS256 (RSA-SHA256), ES256 (ECDSA-SHA256) e none (sem assinatura — proibido em produção). Payload: também chamado de claims, um conjunto de campos JSON. RFC 7519 define 7 claims registrados padrão: iss (emissor), sub (assunto, geralmente um ID de usuário), aud (audiência), exp (expiração), nbf (não antes), iat (emitido em) e jti (ID único). Desenvolvedores podem adicionar qualquer campo privado além desses, como userId, role, tenant. Signature: codifica Header e Payload em Base64URL, junta-os com um ponto e depois assina com o algoritmo especificado por alg usando uma chave. HS256 usa HMAC-SHA256(secret, header_b64 + '.' + payload_b64); RS256 usa uma chave privada RSA. O receptor recalcula a assinatura da mesma forma e verifica se as duas coincidem. Base64URL versus Base64 padrão: '+' vira '-', '/' vira '_' e o preenchimento '=' final é removido, para que o resultado possa ser colocado em caminhos de URL e strings de consulta sem acionar codificação porcentual. Observe que Base64URL é apenas uma codificação — não oferece criptografia nem segurança, e qualquer pessoa pode decodificar e ler o payload. Limite de segurança: JWT só garante 'não foi alterado', não 'o conteúdo é sensível'. Um erro comum é colocar números de telefone, CPF ou hashes de senha no payload, onde todos podem vê-los.
- Estrutura de três partes: Header.Payload.Signature, cada uma codificada em Base64URL; a assinatura é HMAC(secret, header_b64 + '.' + payload_b64) ou RSA(privateKey, mesma entrada).
- Base64URL troca '+' por '-', '/' por '_' e remove o preenchimento '=' final, para que o resultado codificado possa ser colocado diretamente em uma URL (sem acionar codificação porcentual).
- Esta ferramenta verifica localmente apenas assinaturas da família HMAC (HS256/HS384/HS512). Algoritmos assimétricos como RS256 ou ES256 exigem a chave pública fornecida pelo endpoint JWKS do emissor, então a verificação da assinatura precisa acontecer num servidor que detenha a chave pública — a página consegue decodificar header e payload, mas não pode verificá-los.
- Claims padrão: iss (emissor), sub (assunto), aud (audiência), exp (expiração como timestamp Unix em segundos), nbf (não antes), iat (emitido em), jti (JWT ID, previne replay).
- Ataque alg=none: o campo alg deve ser validado estritamente e o algoritmo none deve ser rejeitado, caso contrário um invasor pode forjar qualquer token; ataques de substituição de algoritmo (verificar um token HS256 usando a chave pública como segredo) também devem ser prevenidos.
- JWT não é criptografado: o payload é texto simples codificado em Base64URL, não criptografado; para conteúdo confidencial use JWE (JSON Web Encryption), mas na prática o padrão comum é manter dados sensíveis no backend e referenciá-los através do campo sub.
Exemplos
Token HS256 padrão
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzA1MzEyODAwLCJleHAiOjE3MDUzMTY0MDB9.znHapMygT8K8YZN4K8zM1sV3bKlQ5pY3xE2gR4wN1vM
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"1234567890","name":"Jane Doe","iat":1705312800,"exp":1705316400}
RFC: RFC 7519 seção 3 define os Registered Claim Names (sub, iat, exp)Token expirado
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsImV4cCI6MTYwMDAwMDAwMH0.OxQ0fUKW0z4mK0xJ4vF0uF7eZB9wK3yF8pL2nQ6tX1k
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-123","exp":1600000000}
Status: expirado (exp < agora)
Observação: a claim exp usa NumericDate (segundos desde a época Unix conforme RFC 7519 seção 2)Token com informações de usuário e claims personalizadas
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTQ1NiIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsInRlbmFudCI6ImFjbWUiLCJpYXQiOjE3MDUzMTI4MDAsImV4cCI6MTcwNTMxNjQwMCwiYXVkIjoiYXBpLmV4YW1wbGUuY29tIn0.7Hk2L9oP3qR1mN4vK8xJ2wE5yT6sB0fA9cZ1dG3hI4U
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-456","name":"Alice","role":"admin","tenant":"acme","iat":1705312800,"exp":1705316400,"aud":"api.example.com"}
Observação: role e tenant são claims privadas - não definidas no RFC 7519Checklist de segurança para implementação de JWT
1. Nunca armazene segredos no payload - JWT é codificado, não criptografado
2. Use segredos fortes para HS256 (>= 256 bits / 32 caracteres aleatórios)
3. Prefira RS256/ES256 para verificação por chave pública em sistemas multi-serviço
4. Valide o header alg - rejeite 'none' ou algoritmos inesperados
5. Verifique os timestamps exp, nbf, iat antes de confiar no token
6. Confirme que aud corresponde ao seu serviço para evitar reutilização do token entre apps
7. Armazene em cookies HttpOnly, não em localStorage (proteção contra XSS)
RFC: RFC 8725 (JWT Best Practices) cobre essas considerações de segurançaPerguntas frequentes
Quais são as três partes de um JWT?
Header, payload e assinatura, separados por pontos. O header declara o algoritmo de assinatura e o tipo do token. O payload carrega claims como sub, iss, aud, iat, exp e quaisquer dados customizados. A assinatura permite que o verificador confirme que o token não foi adulterado. Header e payload são JSON codificado em Base64URL — eles são assinados, não criptografados.
Um JWT é criptografado?
Não — um JWT no formato JWS normal é assinado, mas não criptografado. Qualquer pessoa que o intercepte pode decodificar header e payload em Base64URL e ler todos os claims, incluindo IDs de usuário, e-mails e papéis. Trate o conteúdo do JWT como informação pública; nunca coloque senhas ou segredos dentro do payload. Existe JWE (JWT criptografado), mas é bem menos comum.
O que cada claim padrão significa?
iss = issuer (emissor); sub = subject (frequentemente o ID do usuário); aud = audience (destinatário pretendido); exp = expiração (segundos Unix); nbf = not before (não antes de); iat = issued at (emitido em); jti = ID único do token para revogação. Eles são definidos pela RFC 7519. Claims customizados podem ser adicionados livremente — use prefixos para os específicos de fornecedor para evitar colisões.
Como verifico um JWT?
Leia o header alg, use a chave correspondente (HS256 = segredo compartilhado, RS256/ES256 = chave pública do endpoint JWKS do emissor), recompute a assinatura sobre header.payload codificado e compare. Depois confira exp, nbf, iss e aud. Rejeite o token se alg for 'none' ou diferir do que seu servidor espera. Esta ferramenta só verifica assinaturas HS256/HS384/HS512 (segredo compartilhado) localmente; a verificação de RS256/ES256 precisa rodar num servidor que tenha a chave pública.
A verificação é feita no meu navegador?
Sim. A página faz o parse do JWT localmente e verifica assinaturas HS256/HS384/HS512 com HMAC executado em JavaScript dentro do seu navegador. O token nunca chega ao nosso servidor, mas lembre-se de que um JWT é feito para viajar em URLs e cabeçalhos — considere que qualquer JWT copiado pode aparecer em logs.
Por que alg=none é perigoso?
A RFC 7519 permite alg=none para tokens sem assinatura. Um verificador vulnerável pode aceitar tal token mesmo sem assinatura, deixando um atacante forjar qualquer payload. Bibliotecas modernas rejeitam alg=none por padrão; se você escrever um verificador, fixe no código o algoritmo esperado em vez de confiar no header.
Quão grande um JWT pode ficar?
Não há limite no protocolo, mas JWTs normalmente acabam em headers HTTP (Authorization: Bearer ...) e muitos servidores limitam headers em torno de 8 KB. Encher um JWT de claims engorda toda requisição. Se você precisa de muito estado de sessão, use uma sessão no servidor e coloque um token de referência pequeno no JWT.