1001Ferramentas
🔐Validadores

Validador de JWT

Verifique se um JWT tem estrutura válida (3 segmentos), header e payload decodificáveis em base64url, e mostra exp, iat, nbf e quaisquer claims. Tudo no navegador.

Esta ferramenta apenas verifica formato e decodifica — não valida assinatura.

Estrutura de um JWT e o que pode significar "válido"

Um JSON Web Token (JWT, RFC 7519) tem três segmentos codificados em base64url separados por pontos: header.payload.signature. O header declara o algoritmo de assinatura (alg) e o tipo do token. O payload carrega claims — padrão como iss (emissor), sub (sujeito), aud (audiência), exp (expiração), nbf (não-antes), iat (emitido em) e jti (ID do token) — mais qualquer dado custom que o emissor queira. A assinatura é computada sobre base64url(header) + "." + base64url(payload) usando o algoritmo do header.

Esta página verifica apenas o lado sintático: três segmentos, base64url válido, JSON que faz parse, claims com os tipos esperados e o token não expirado. Ela não verifica a assinatura criptográfica — isso exige o segredo (para HMAC) ou a chave pública (para RSA/ECDSA) do emissor, e nenhum desses está disponível aqui.

Algoritmos de assinatura

  • HS256 / HS384 / HS512 — HMAC com SHA-2. Simétrico: o mesmo segredo assina e verifica. Bom para monolitos.
  • RS256 / RS384 / RS512 — RSA-PKCS#1 v1.5 com SHA-2. Assimétrico: chave privada assina, pública verifica. Padrão em OAuth/OIDC.
  • ES256 / ES384 — ECDSA sobre P-256 / P-384. Assimétrico, assinatura muito mais curta que RSA.
  • EdDSA — Ed25519 (ou Ed448). Rápido, moderno, tempo constante.
  • PS256 / PS384 / PS512 — RSA-PSS, esquema de padding RSA recomendado.

Ataques comuns e como prevenir

O ataque alg: none (CVE-2015-9235): um token malicioso seta alg como none e envia sem assinatura; bibliotecas que confiam cegamente no header aceitam. Mitigação: nunca deixe o token escolher o algoritmo — fixe uma allowlist no servidor.

O ataque de confusão de algoritmo: token forjado com HS256 usando a chave pública RSA do emissor como segredo HMAC. Se o servidor chama cegamente verify(token, publicKey) sem checar o algoritmo, a forjadura passa. Mitigação: a API de verificação deve exigir explicitamente o algoritmo esperado.

Outros clássicos: replay de token expirado se você ignora exp, confusão de audiência se você pula a validação de aud, confusão de chave via headers jku/x5u apontando para URLs controladas pelo atacante e envenenamento de JWKS quando um endpoint /.well-known/jwks.json desprotegido serve chaves injetadas pelo atacante.

Armazenamento, tamanho do payload e boas práticas

Use expirações curtas — 15 minutos para access tokens, com refresh tokens de vida mais longa guardados separadamente. Guarde os tokens em cookies HttpOnly, Secure, SameSite=Strict, nunca em localStorage (qualquer XSS lê na hora). Sempre valide iss e aud contra os valores esperados. Rotacione chaves de assinatura via JWKS e inclua um kid (key ID) no header para que verificadores escolham a chave certa.

Nunca coloque PII sensível no payload de um JWT — base64url é codificação, não criptografia. Se precisar de confidencialidade, use JWE (criptografado) em vez do JWS (assinado) puro. Bibliotecas recomendadas: jose (Node, ESM-first, sem CVEs históricos), jsonwebtoken (Node, mais antigo, vários CVEs históricos em torno do tratamento de algoritmo), PyJWT (Python), jjwt (Java).

Perguntas frequentes

Posso decodificar um JWT sem o segredo? Sim — decodificar base64url é trivial e revela header e payload em texto claro. Por isso você nunca deve guardar senha, número de cartão ou outras PII dentro. O segredo só é necessário para verificar ou forjar a assinatura, não para ler o conteúdo.

Como evitar o ataque alg: none? Configure a biblioteca de verificação com allowlist explícita de algoritmos. Em jsonwebtoken no Node, isso é jwt.verify(token, key, { algorithms: ['RS256'] }) — nunca omita essa opção.

Onde guardar o refresh token? Em um cookie HttpOnly, Secure, SameSite=Strict atrelado a um endpoint específico de refresh. Nunca em armazenamento legível por JavaScript e nunca no mesmo path do access token.

Qual o tamanho máximo de um JWT? Não há limite rígido, mas o token vai em todo request no header Authorization. Headers acima de 8 KB costumam ser rejeitados por proxies e CDNs. Mantenha as claims enxutas; se você tem muito estado, guarde no servidor e bote só um ID opaco no JWT.

Ferramentas Relacionadas

Leia mais sobre isso