Depurador JWT

Depurador JWT (Decodificar & Validar)

Depure tokens JWT online com segurança. Decodifique claims de cabeçalho e payload, valide assinaturas HS256, RS256 e ES256 e inspecione a expiração localmente no navegador.

Predefinições:
Token JWT Codificado
Cabeçalho (JOSE)(74B)
.
Payload (Claims)(248B)
.
Assinatura (Cripto)(342B)
PKCS#1 / X.509 SPKI
Tolerância de Desvio de Relógio (Clock Skew):
60s
Length: 666 charsSegments: 3/3
Cabeçalho (JOSE) • Payload (Claims) • Assinatura (Cripto)
Expiration (exp): 244d ago
Cabeçalho Decodificado (JOSE)alg: RS256
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "auth0-key-2026-prod"
}
Payload Decodificado (Claims Registrados & Privados)6 registered & custom claims
{
  "iss": "https://auth.example.com/",
  "sub": "auth0|64f1a2b3c4d5e6f7",
  "aud": "https://api.example.com/v2/",
  "iat": 1772500000,
  "exp": 1772586400,
  "scope": "read:profile write:reports openid email"
}
iss (Issuer): https://auth.example.com/
sub (Subject): auth0|64f1a2b3c4d5e6f7
aud (Audience): "https://api.example.com/v2/"
iat (Issued At): 245d ago
Status:UNVERIFIED|Time: 0ms
Tamanho do Token666 B
AlgoritmoRS256
Status de ExpiraçãoToken Expirado
Saúde de Segurança85/100
Status da AssinaturaAssinatura Não Verificada - Forneça a Chave Secreta ou Certificado
Total de Claims6 Claims

Processamento no Cliente

Cálculo de alta performance executado inteiramente na memória do navegador.

Privacidade Zero Upload

Todos os payloads permanecem estritamente locais, sem comunicação com servidores externos.

Exportação Pronta para Produção

Formatos de saída limpos e otimizados, prontos para implantação imediata.

ToolsAA•Utilitários web 100% privados no cliente
Referência técnica e guia de arquitetura

JWT Debugger & Validador de Tokens — Guia de referência

Depure tokens JWT online com nosso JWT debugger. Decodifique claims do header e payload, valide assinaturas HS256, RS256 e ES256 e verifique a expiração localmente.

JWT Debugger & Validador de Tokens — Guia de referência — Arquitetura em memória do lado do cliente e fluxo de dados
JWT Debugger & Validador de Tokens — Guia de referência — Arquitetura em memória do lado do cliente e fluxo de dados

Parâmetros-chave e controles

Cabeçalho JOSE (Javascript Object Signing and Encryption)Objeto JSON (Especificação RFC 7515 JWS)

Especifica o algoritmo criptográfico ('alg': HS256, RS256, ES256) e o tipo de token ('typ': 'JWT'). Deve impor allowlists estritas de algoritmos no verificador para bloquear ataques de confusão de algoritmo. Analisado em tempo de varredura linear O(n) sem retrocesso (backtracking) de regex.

Padrão: {"alg":"HS256","typ":"JWT"}
Payload de Claims JWT (Conjunto de Claims RFC 7519)Objeto JSON (Especificação RFC 7519)

Contém asserções de identidade, metadados de entidades e escopos de acesso. As claims registradas padrão incluem 'sub' (subject), 'iss' (emissor), 'aud' (audiência), 'iat' (emitido em) e 'exp' (expiração em segundos da época POSIX). A sandbox local da Web Crypto API decodifica claims em tempo O(n) com zero transmissão de rede externa.

Padrão: {"sub":"user_123","iat":1772500000,"exp":1772503600}
Assinatura Compacta JWSDigest Criptográfico Binário em Base64URL

Digest criptográfico gerado pela assinatura de 'Base64URL(Header) + "." + Base64URL(Payload)' com a chave privada ou segredo compartilhado. Verifica a autenticidade da mensagem e a integridade do payload usando comparação em tempo constante contra ataques de canal lateral baseados em temporização (timing side-channel attacks).

Padrão: Assinatura HMAC ou RSA codificada em Base64URL
Segredo Compartilhado HMAC / Chave Pública PEMMaterial de Chave Criptográfica (SPKI PEM / Segredo Bruto)

Chave criptográfica utilizada para verificar a assinatura. O HS256 exige um segredo mínimo de 256 bits (32 bytes) para prevenir ataques de força bruta offline por dicionário; o RS256 requer uma chave pública RSA SPKI PEM de 2048 bits ou 4096 bits; o ES256 requer uma chave pública P-256 (secp256r1) importada via Web Crypto API crypto.subtle.importKey().

Padrão: seu-segredo-de-256-bits
Tolerância de Desvio de Relógio (Leeway)Limite de Deslocamento Temporal (Segundos)

Variação de tempo operacional permitida (intervalo padrão: 30 a 120 segundos, benchmark: 60 segundos) para compensar o desvio de relógio do Network Time Protocol (NTP) entre o emissor da autenticação e os verificadores de recursos durante a validação das claims 'exp' e 'nbf'.

Padrão: 60 segundos

Dicas profissionais e melhores práticas

Nunca confie apenas na decodificação de JWT no cliente (valide a assinatura no servidor de recursos)

Decodificar um JWT via Base64URL no JavaScript do frontend revela claims para personalização de UI (como exibir o nome de usuário), mas não comprova nenhuma autenticidade. Um agente malicioso pode adulterar claims do payload como 'role: admin' em segundos. Gateways de API e servidores de backend em produção devem verificar matematicamente a assinatura JWS usando um segredo ou chave pública confiável antes de autorizar requisições.

Defenda-se contra o ataque de bypass criptográfico 'alg: none' (RFC 8725 §3.1)

A RFC 7519 permite o tipo de token 'alg: none' para contextos sem segurança. Bibliotecas de verificação vulneráveis aceitam tokens 'alg: none' com um bloco de assinatura vazio, permitindo que atacantes forjem claims arbitrárias. Sempre configure seu middleware de verificação JWT com uma allowlist explícita de algoritmos (por exemplo, algorithms: ['RS256']) e rejeite tokens em que 'alg' seja 'none' ou divirja da cifra esperada.

Imponha a entropia mínima de 256 bits para segredos HS256 (RFC 7518 §3.2)

Assinaturas simétricas HMAC são tão seguras quanto a força do segredo compartilhado. Se um segredo HS256 for uma palavra comum ou tiver menos de 32 bytes (256 bits), ferramentas de força bruta offline como o hashcat podem quebrar o segredo em segundos a partir de tokens interceptados. Utilize chaves de 256 bits criptograficamente aleatórias geradas via 'crypto.getRandomValues(new Uint8Array(32))' ou um CSPRNG seguro.

Mitigue ataques de confusão de chave entre cifras simétricas e assimétricas (RFC 8725 §3.2)

Em um ataque de confusão de algoritmo, o invasor altera o cabeçalho de um token RS256 para 'HS256' e o assina usando a chave pública RSA do servidor como o segredo compartilhado HMAC. Se a biblioteca de verificação do backend avaliar algoritmos dinamicamente sem validação estrita do tipo de chave, ela validará o token forjado. Defenda-se fixando algoritmos esperados por endpoint e segregando estritamente os repositórios de chaves HMAC e RSA.

O payload do JWT é codificado, NÃO criptografado (nunca armazene senhas ou PII)

Um JWT padrão é uma JWS (JSON Web Signature) assinada, e não uma JWE (JSON Web Encryption) criptografada. O payload é meramente codificado em Base64URL e pode ser lido por qualquer pessoa com acesso à rede ou ao console do navegador. Nunca armazene credenciais de banco de dados, senhas puras, CPF/RG, números de segurança social ou dados financeiros confidenciais nas claims de um JWT.

Armadilhas comuns e solução de problemas

⚠️Erro de assinatura inválida (SignatureVerificationException) mesmo com o segredo correto

Esse erro ocorre quando a chave secreta é codificada em Base64 no servidor de autenticação (comum no Supabase e Auth0), mas inserida como texto puro UTF-8 no verificador. Verifique se a opção 'Base64 Secret' está habilitada caso seu segredo utilize essa codificação. Certifique-se também de que quebras de linha ('\n') ou aspas residuais não foram coladas acidentalmente junto com o segredo.

⚠️Erro de token expirado (TokenExpiredError: jwt expired) imediatamente após a geração

As claims 'exp' e 'iat' do JWT são expressas em segundos desde a época Unix (10 dígitos), e não em milissegundos (13 dígitos). Se o seu backend define 'exp: Date.now()', o timestamp apontará para um futuro distante ou, se dividido de forma incorreta, para o ano de 1970. Utilize 'Math.floor(Date.now() / 1000) + lifetimeInSeconds' e configure uma tolerância (leeway) de desvio de relógio de 60 segundos no verificador.

⚠️Falha na verificação RS256 com erro 'Invalid Key Format' ou erro de SPKI PEM

O RS256 requer uma chave pública SubjectPublicKeyInfo (SPKI) PEM iniciando com '-----BEGIN PUBLIC KEY-----' e terminando com '-----END PUBLIC KEY-----'. Se você estiver usando um certificado PKCS#1 iniciando com '-----BEGIN RSA PUBLIC KEY-----' ou um endpoint JWKS, converta a chave para o formato SPKI padrão ou extraia a cadeia de certificados x5c para um envelope PEM válido.

⚠️Erro de token malformado: o JWT não contém exatamente dois delimitadores de ponto

Um JWT compacto válido segundo a RFC 7519 contém exatamente dois delimitadores de ponto separando três segmentos Base64URL (Header.Payload.Signature). Ao copiar um token de uma requisição HTTP, remova prefixos como 'Bearer ', sequências de escape de query URL ('%2E') ou quebras de linha ('\r\n') antes de realizar a análise.

Perguntas frequentes (FAQ)

Como validar uma assinatura JWT e quais componentes matemáticos são necessários?▼

Para verificar a assinatura de um JWT, pegue o header e o payload codificados em Base64URL exatamente como foram concatenados por ponto ('header.payload'), calcule o digest criptográfico usando o algoritmo especificado no cabeçalho ('alg') e a chave do servidor, e compare o digest resultante com a assinatura decodificada em Base64URL. No HS256, isso exige HMAC-SHA256 com um segredo compartilhado; no RS256, exige verificação RSA-SHA256 utilizando a chave pública do emissor.

Qual é a diferença entre HS256 e RS256 na autenticação com JWT?▼

O HS256 é um algoritmo simétrico no qual a mesma chave secreta é utilizada tanto para assinar quanto para verificar tokens, sendo indicado quando o emissor e o gateway de API compartilham um perímetro interno seguro. Já o RS256 é um algoritmo assimétrico em que o servidor de autenticação assina tokens com uma chave privada e os servidores de recursos verificam tokens usando um certificado público, permitindo que microsserviços e sistemas terceiros validem a autenticidade sem expor a chave de assinatura privada.

Um token JWT pode ser modificado ou adulterado sem invalidar a assinatura?▼

Não. Qualquer alteração no cabeçalho ou no payload — como elevar o perfil de 'user' para 'admin' ou estender o timestamp de expiração — altera a entrada criptográfica da função de hash. Sem a posse da chave privada original ou do segredo compartilhado, um atacante não consegue produzir uma assinatura válida correspondente, fazendo com que qualquer verificador em conformidade rejeite imediatamente o token com erro de assinatura inválida.

Por que nunca devemos armazenar dados sensíveis como senhas ou cartões no payload do JWT?▼

Porque tokens JWT convencionais são apenas assinados digitalmente (JWS), e não criptografados (JWE). O payload é apenas codificado em Base64URL, o que oferece confidencialidade zero. Qualquer pessoa que intercepte o token em trânsito, inspecione o tráfego de rede ou visualize o armazenamento local (como localStorage) pode decodificar instantaneamente o payload em Base64URL e ler todas as claims contidas em texto puro.

O que são claims registradas de um JWT e o que significam iat, exp e nbf?▼

Claims registradas são chaves de metadados padronizadas pela RFC 7519: 'iat' (Issued At) define o timestamp da época Unix em que o token foi gerado; 'exp' (Expiration Time) determina o momento a partir do qual o token deve ser rejeitado; 'nbf' (Not Before) especifica o instante exato antes do qual o token não é válido; 'iss' identifica o emissor do token; 'sub' representa o sujeito principal (usuário ou serviço); e 'aud' define o público ou audiência destinatária pretendida.

Ferramentas e utilitários relacionados

Todas as ferramentas →
Gerador de CSP & Content Security PolicySegurança

Gere cabeçalhos Content Security Policy (CSP) seguros instantaneamente. Configure script-src, style-src, nonces e hashes para mitigar ataques XSS e corrigir erros de CSP.

Abrir ferramenta→
Gerador de Hash Bcrypt e Verificador de SenhasSegurança

Gere hashes de senha criptograficamente seguros em Eksblowfish com rounds de salt ajustáveis (4-16) e verifique senhas localmente no navegador.

Abrir ferramenta→
Gerador e Verificador de Assinaturas HMACSegurança

Calcule e valide códigos de autenticação de mensagens RFC 2104 (HMAC-SHA256, HMAC-SHA512, HMAC-SHA1, HMAC-MD5) com verificação em tempo constante (Timing-Safe) no navegador.

Abrir ferramenta→
Criptografador e Descriptografador AES-GCM / CBC no ClienteSegurança

Criptografia autenticada AES-256 acelerada por hardware executada estritamente no seu navegador via Web Crypto API. Zero retenção em servidores.

Abrir ferramenta→
Gerador de Chaves RSA Pública e PrivadaSegurança

Crie pares de chaves RSA criptograficamente seguras (2048 e 4096 bits) em formato PEM PKCS#8 utilizando a Web Crypto API do navegador.

Abrir ferramenta→
Codificador e Decodificador Base58 / Base58CheckSegurança

Converta texto e bytes hexadecimais em Base58 e Base58Check compatível com Bitcoin e IPFS, com cálculo de checksum SHA-256 duplo.

Abrir ferramenta→