O Que e um JSON Web Token?

JWT (RFC 7519) e um padrão aberto para representar claims (afirmacoes) entre duas partes como um objeto JSON assinado. E onipresente em autenticação de APIs modernas, OAuth 2.0 e OpenID Connect.

Estrutura de um JWT

Um JWT tem três segmentos codificados em Base64URL e separados por ponto:

  • Header - metadados: algoritmo (alg) e tipo (typ)
  • Payload - claims (identidade, permissões, expiração...)
  • Signature - HMAC ou assinatura digital sobre header+payload

Claims padronizados (RFC 7519)

  • iss (Issuer) - quem emitiu
  • sub (Subject) - sujeito (geralmente user ID)
  • aud (Audience) - destinatário pretendido
  • exp (Expiration) - timestamp Unix de expiração
  • nbf (Not Before) - valido a partir de
  • iat (Issued At) - quando foi emitido
  • jti (JWT ID) - identificador único (útil para revogar)
JWT não e criptografado por padrão

O header e payload são apenas codificados em Base64URL, não cifrados. Qualquer pessoa com acesso ao token pode ler seu conteúdo. A assinatura garante integridade (não foi adulterado), não confidencialidade. Nunca coloque senhas, CPF, chaves privadas ou dados sensíveis no payload. Se precisar confidencialidade, use JWE.

Vulnerabilidades Comuns em JWT

1. alg=none

A especificacao permite alg=none, indicando token sem assinatura. Implementacoes vulneráveis aceitavam esse valor e confiavam no payload, permitindo que atacantes forjassem qualquer token - por exemplo, trocando "role":"user" por "role":"admin". Documentado em CVE-2015-9235. Sempre rejeite alg=none no servidor e valide o algoritmo explicitamente.

2. Algorithm confusion (RS256 → HS256)

Implementacoes antigas aceitavam a chave publica RSA (que e publica!) como se fosse segredo HMAC. Atacantes pegavam a chave publica do servidor, trocavam alg para HS256 e assinavam um token com ela. Sempre valide que o alg do token bate com o alg esperado pela aplicação.

3. kid injection

Header kid (Key ID) e usado para selecionar qual chave verificar. Se a aplicação usa o valor para carregar arquivos (keys/{kid}.pem), atacantes podem injetar caminhos como ../../etc/passwd ou apontar para arquivos previsiveis. Faça allowlist de kids permitidos.

4. Brute force de segredo HMAC

Se o token usa HS256 (HMAC-SHA256) com segredo fraco, atacantes podem tentar brute-force offline. Ferramentas como hashcat (modo 16500) testam bilhões de senhas por segundo. Use segredos gerados aleatoriamente com pelo menos 32 bytes (256 bits) de entropia, ou prefira RS256/ES256.

5. Falta de validação de exp/aud

Servidores que decodificam o token mas não validam exp, nbf, iss e aud podem aceitar tokens expirados ou emitidos para outro serviço. Sempre valide todas as claims relevantes, de preferencia usando uma biblioteca JWT madura que faz isso por você.

Boas Práticas para Usar JWT

Do lado do servidor

  • Valide o algoritmo explicitamente - nunca confie no header
  • Rejeite alg=none sem exceção
  • Use segredos fortes (32+ bytes aleatorios) para HMAC
  • Prefira RS256 ou ES256 para sistemas distribuidos (chave publica verificada por vários serviços, privada só no emissor)
  • Valide exp, nbf, iat, iss, aud em toda requisição
  • Implemente revogação - lista de jtis revogados ou tokens de vida muito curta + refresh
  • Use access tokens curtos (15-60 min) + refresh tokens

Do lado do cliente

  • Nunca armazene em localStorage - vulnerável a XSS
  • Use cookies HttpOnly + Secure + SameSite=Strict
  • Considere o padrão BFF (Backend for Frontend) para SPAs
  • Não exponha JWTs em logs - use request IDs em seu lugar

Quando Usar JWT (e Quando Não)

Bom para

  • APIs stateless (verificar sem consultar banco)
  • Single Sign-On (SSO) entre serviços
  • OAuth 2.0 / OpenID Connect (padrão de facto)
  • Comunicação máquina-a-máquina

Evitar para

  • Sessões tradicionais de aplicação web - use cookie de sessão com store server-side (mais simples, fácil de revogar)
  • Armazenar dados sensíveis no payload
  • Tokens de longa duração sem mecanismo de revogação

Perguntas Frequentes

O que e um JWT (JSON Web Token)?

JWT (RFC 7519) e um padrão aberto para representar claims entre duas partes como JSON assinado. Tem três segmentos Base64URL separados por ponto: header.payload.signature. Usado em APIs, OAuth e OpenID Connect.

JWT e criptografado?

Por padrão não. Header e payload são apenas codificados em Base64URL - legiveis. A assinatura garante integridade, não confidencialidade. Para confidencialidade, use JWE ou só trafegue por TLS sem dados sensíveis no payload.

O que e o ataque alg=none em JWT?

Bibliotecas vulneráveis aceitavam tokens com alg=none (sem assinatura), permitindo que atacantes forjassem qualquer claim (CVE-2015-9235). Sempre rejeite alg=none e valide o algoritmo esperado.

Onde devo armazenar JWT no cliente?

Evite localStorage (XSS). Use cookies HttpOnly + Secure + SameSite=Strict com tokens curtos e rotação. Para SPAs, considere BFF (Backend for Frontend) mantendo token no backend.

Este decoder envia meu token a algum servidor?

Não. Toda decodificacao acontece no seu navegador via atob() e JSON.parse(). Tokens podem conter credenciais sensíveis e não deveriam ser colados em serviços online sem essa garantia.

Outras Ferramentas Gratuitas

Codificador Base64/URL/Hex

Decode manualmente os segmentos de um JWT ou outras strings Base64URL.

Calculadora de Hash

Calcule HMAC-SHA256 usado como assinatura em JWTs HS256 (requer segredo).

Gerador de Senhas

Gere segredos fortes (32+ bytes) para assinar tokens HMAC.

Sua API esta segura? Faça um pentest especializado

Nossa equipe revisa implementacoes de JWT, OAuth, OpenID Connect e detecta vulnerabilidades como alg=none, algorithm confusion e kid injection.

Solicitar Proposta