O Que e um JSON Web Token?

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

Estrutura de um JWT

Um JWT tem tres segmentos codificados em Base64URL e separados por ponto:

  • Header - metadados: algoritmo (alg) e tipo (typ)
  • Payload - claims (identidade, permissoes, expiracao...)
  • Signature - HMAC ou assinatura digital sobre header+payload

Claims padronizados (RFC 7519)

  • iss (Issuer) - quem emitiu
  • sub (Subject) - sujeito (geralmente user ID)
  • aud (Audience) - destinatario pretendido
  • exp (Expiration) - timestamp Unix de expiracao
  • nbf (Not Before) - valido a partir de
  • iat (Issued At) - quando foi emitido
  • jti (JWT ID) - identificador unico (util para revogar)
JWT nao e criptografado por padrao

O header e payload sao apenas codificados em Base64URL, nao cifrados. Qualquer pessoa com acesso ao token pode ler seu conteudo. A assinatura garante integridade (nao foi adulterado), nao confidencialidade. Nunca coloque senhas, CPF, chaves privadas ou dados sensiveis no payload. Se precisar confidencialidade, use JWE.

Vulnerabilidades Comuns em JWT

1. alg=none

A especificacao permite alg=none, indicando token sem assinatura. Implementacoes vulneraveis 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 aplicacao.

3. kid injection

Header kid (Key ID) e usado para selecionar qual chave verificar. Se a aplicacao usa o valor para carregar arquivos (keys/{kid}.pem), atacantes podem injetar caminhos como ../../etc/passwd ou apontar para arquivos previsiveis. Faca 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 bilhoes de senhas por segundo. Use segredos gerados aleatoriamente com pelo menos 32 bytes (256 bits) de entropia, ou prefira RS256/ES256.

5. Falta de validacao de exp/aud

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

Boas Praticas para Usar JWT

Do lado do servidor

  • Valide o algoritmo explicitamente - nunca confie no header
  • Rejeite alg=none sem excecao
  • Use segredos fortes (32+ bytes aleatorios) para HMAC
  • Prefira RS256 ou ES256 para sistemas distribuidos (chave publica verificada por varios servicos, privada so no emissor)
  • Valide exp, nbf, iat, iss, aud em toda requisicao
  • Implemente revogacao - 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 - vulneravel a XSS
  • Use cookies HttpOnly + Secure + SameSite=Strict
  • Considere o padrao BFF (Backend for Frontend) para SPAs
  • Nao exponha JWTs em logs - use request IDs em seu lugar

Quando Usar JWT (e Quando Nao)

Bom para

  • APIs stateless (verificar sem consultar banco)
  • Single Sign-On (SSO) entre servicos
  • OAuth 2.0 / OpenID Connect (padrao de facto)
  • Comunicacao maquina-a-maquina

Evitar para

  • Sessoes tradicionais de aplicacao web - use cookie de sessao com store server-side (mais simples, facil de revogar)
  • Armazenar dados sensiveis no payload
  • Tokens de longa duracao sem mecanismo de revogacao

Perguntas Frequentes

O que e um JWT (JSON Web Token)?

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

JWT e criptografado?

Por padrao nao. Header e payload sao apenas codificados em Base64URL - legiveis. A assinatura garante integridade, nao confidencialidade. Para confidencialidade, use JWE ou so trafegue por TLS sem dados sensiveis no payload.

O que e o ataque alg=none em JWT?

Bibliotecas vulneraveis 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 rotacao. Para SPAs, considere BFF (Backend for Frontend) mantendo token no backend.

Este decoder envia meu token a algum servidor?

Nao. Toda decodificacao acontece no seu navegador via atob() e JSON.parse(). Tokens podem conter credenciais sensiveis e nao deveriam ser colados em servicos 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? Faca 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