Garantia de privacidade: Esta ferramenta roda inteiramente no seu navegador. Nenhuma requisicao de rede e feita. Seus dados de token permanecem no seu dispositivo.

O Que e um JSON Web Token (JWT)?

Um JSON Web Token (JWT) e um padrao aberto (RFC 7519) para transmitir informacoes entre partes de forma segura como um objeto JSON. JWTs sao comumente usados para autenticacao e troca de informacoes em APIs web. O token e assinado digitalmente, para que voce possa verificar sua integridade — mas por padrao o payload e apenas codificado em Base64, nao criptografado.

Um JWT consiste em tres partes separadas por pontos: Header (algoritmo e tipo do token), Payload (claims/dados) e Signature (usada para verificar que o token nao foi adulterado).

Claims Padrao do JWT

  • iss (Issuer) — Quem criou e assinou o token
  • sub (Subject) — Sobre quem e o token (geralmente ID do usuario)
  • aud (Audience) — Para quem o token e destinado
  • exp (Expiration Time) — Quando o token expira (timestamp Unix)
  • iat (Issued At) — Quando o token foi emitido
  • nbf (Not Before) — O token nao e valido antes deste horario
  • jti (JWT ID) — Identificador unico para o token

Dicas de Seguranca JWT

  • Nunca armazene dados sensiveis em payloads JWT — o payload e apenas codificado em Base64, nao criptografado. Qualquer pessoa pode decodifica-lo.
  • Sempre verifique a assinatura no lado do servidor — um JWT decodificado nao significa que e valido. Sempre verifique a assinatura contra sua chave secreta.
  • Mantenha tempos de expiracao curtos — use refresh tokens para sessoes longas. Access tokens de curta duracao (15-60 min) limitam a exposicao.
  • Evite o algoritmo "none" — algumas implementacoes vulneraveis aceitam tokens nao assinados. Sempre imponha um algoritmo especifico.
  • Use apenas HTTPS — transmita JWTs apenas por conexoes criptografadas para evitar interceptacao.

Melhores Práticas de Segurança JWT para Produção

Os JSON Web Tokens são amplamente usados para autenticação, mas uma implementação inadequada cria vulnerabilidades de segurança sérias. Siga estas práticas testadas em batalha ao implantar JWTs em sistemas de produção.

Armazenamento de Tokens: Onde Guardar os JWTs

  • Cookies HttpOnly (Recomendado): Armazene os JWTs em cookies HttpOnly, Secure, SameSite=Strict. Isso previne o acesso via JavaScript, eliminando o roubo de tokens baseado em XSS. O navegador envia automaticamente o cookie com cada requisição.
  • localStorage (Evitar): Qualquer vulnerabilidade XSS no seu app ou scripts de terceiros pode ler o localStorage e roubar o token. Nunca armazene tokens sensíveis em localStorage para aplicações de produção.
  • sessionStorage: Ligeiramente melhor que localStorage pois limpa ao fechar a aba, mas ainda vulnerável a ataques XSS durante a sessão.
  • Em memória (SPAs): Armazene o token em uma variável JavaScript. Mais seguro contra XSS, mas o token é perdido ao atualizar a página, exigindo re-autenticação silenciosa via refresh tokens.

Vulnerabilidades Comuns de JWT e Mitigações

  • Ataque de Confusão de Algoritmo: Um atacante altera o cabeçalho alg de RS256 para HS256, então assina o token com a chave pública. Sempre valide o algoritmo no lado do servidor e rejeite valores de algoritmo inesperados.
  • Expiração do Token Muito Longa: Access tokens devem expirar em 15–30 minutos. Use access tokens de curta duração junto com refresh tokens de maior duração (7–30 dias) armazenados de forma segura no servidor.
  • Falta de Validação de Audience/Issuer: Sempre verifique os claims aud (audience) e iss (issuer) para prevenir que tokens de um serviço sejam aceitos por outro.
  • Sem Revogação de Tokens: JWTs são stateless — uma vez emitidos, são válidos até a expiração. Implemente uma lista de bloqueio de tokens (usando Redis) para logout, mudanças de senha e contas comprometidas.

JWT vs Autenticação Baseada em Sessões

JWTs são ideais para APIs stateless, arquiteturas de microsserviços e apps móveis onde o armazenamento de sessões no servidor é impraticável. A autenticação baseada em sessões é melhor para apps web tradicionais renderizados no servidor onde você precisa de revogação instantânea e não quer gerenciar lógica de refresh de tokens. Muitos sistemas de produção usam uma abordagem híbrida: JWTs entre microsserviços internamente, com cookies de sessão para o frontend voltado ao usuário.

Perguntas Frequentes sobre JWT

E seguro decodificar um token JWT no navegador?

Sim, decodificar um JWT e sempre seguro porque o header e o payload sao apenas codificados em Base64URL, nao criptografados. Qualquer pessoa que tenha o token pode ler seu conteudo — isso e intencional. Esta ferramenta decodifica seu JWT inteiramente no seu navegador; seu token nunca e enviado para nenhum servidor. Por isso voce nunca deve armazenar senhas, chaves privadas ou segredos sensiveis em um payload JWT.

Posso verificar a assinatura de um JWT sem a chave secreta?

Nao. A verificacao da assinatura JWT requer a chave secreta (para algoritmos HMAC como HS256) ou a chave publica (para RS256, ES256). Voce sempre pode decodificar o header e o payload sem uma chave, mas nao pode verificar se o token foi adulterado. A verificacao da assinatura deve ser feita no lado do servidor. Esta ferramenta mostra o conteudo decodificado do token para inspecao, nao a validade da assinatura.

Por que meu token JWT esta expirando inesperadamente?

Tokens JWT contem uma claim exp — um timestamp Unix de quando o token expira. Se o horario atual exceder esse valor, o token e rejeitado. Isso e intencional por seguranca. Verifique o valor exp aqui para entender quando seu token expira. Se os tokens expiram muito rapido, verifique a diferenca de relogio entre seu servidor e cliente — mesmo poucos minutos de diferenca causam problemas. Use NTP para manter os relogios dos servidores sincronizados.

Qual algoritmo devo usar para assinar tokens JWT?

Para a maioria das aplicacoes, RS256 (RSA + SHA-256) e recomendado porque usa chaves assimetricas — voce assina com uma chave privada e verifica com uma chave publica, podendo compartilhar a chave publica com seguranca. HS256 (HMAC + SHA-256) e mais simples, mas requer compartilhar a chave secreta com cada servico que verifica tokens. Nunca use o algoritmo "none" — algumas implementacoes vulneraveis aceitam tokens nao assinados, o que e uma falha de seguranca critica.

Ferramentas Relacionadas para Desenvolvedores