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
Validador de @handle do Twitter/X
Valida formato de @handle do Twitter/X: 1-15 caracteres, letras, dígitos e _. Não verifica se está em uso (verificação seria server-side).
Validador de Cor Hexadecimal
Valide cores hex no formato #RGB, #RGBA, #RRGGBB ou #RRGGBBAA e converta entre eles. Tudo no navegador.
Validador de Google Tag Manager ID
Valida formato do GTM ID: GTM-XXXXXXX (7 caracteres alfanuméricos após GTM-). Útil em auditorias de implementação.