Guia da ferramenta
Sobre Decodificador e analisador JWT
Um parser JWT decodifica Header e Payload de um JSON Web Token para inspecionar alg, typ, estado da assinatura e claims comuns como iss, sub, aud, iat, nbf e exp.
A ferramenta analisa tokens localmente no navegador e pode re-assinar Header/Payload editados com um segredo HMAC local. O token não é enviado ao wetool.site.
Como usar o JWT Parser
- Cole um JWT completo no formato header.payload.signature.
- Clique em Decode para ver Header, Payload e resumo dos claims comuns.
- Confira exp, nbf e iat; normalmente são segundos Unix.
- Para tokens HMAC de teste, informe um secret para re-assinar localmente o Header/Payload editado.
Quando usar
- Depurar uma sessão de auth verificando se o token expirou ou ainda não está válido.
- Confirmar se alg, typ, iss, aud e sub batem com o contrato do API gateway ou backend.
- Formatar o payload JSON para encontrar scope, role, tenant_id ou outros campos da aplicação.
- Editar um claim de token de desenvolvimento e re-assinar localmente com um HMAC secret conhecido.
Estrutura JWT, claims e limites da assinatura
Um JWT normalmente tem três partes Base64URL: Header, Payload e Signature. Decodificar Header/Payload não exige secret, mas confiar no token exige verificar a assinatura com a chave correta.
- Header: geralmente contém alg e typ, descrevendo algoritmo de assinatura e tipo de token.
- Payload: contém claims como iss, sub, aud, iat, nbf, exp e campos da aplicação.
- Signature: protege Header/Payload contra alteração; decodificar um token não prova que a assinatura é válida.
- Claims de tempo: iat, nbf e exp geralmente são expressos em segundos Unix, não em milissegundos.
Perguntas frequentes sobre Analisador JWT
- Decodificar JWT é o mesmo que verificar?
- Não. Decodificar apenas lê Header e Payload. Verificar exige checar a assinatura com o secret ou public key correto.
- Por que consigo ler o payload sem senha?
- Header e Payload são Base64URL encoding, não encryption. Não coloque segredos em um JWT payload comum.
- O que são exp, iat e nbf?
- exp é a expiração, iat é a data de emissão e nbf é o momento a partir do qual o token vale. Normalmente são armazenados como segundos Unix.
- Um token funciona depois de editar o Payload?
- Normalmente não, a menos que seja re-assinado. A ferramenta pode re-assinar tokens HMAC de teste localmente com o secret.
- Meu JWT é enviado?
- Não. Decoding, edição e re-assinatura HMAC rodam localmente no navegador e não são enviados ao wetool.site.
JWT vs cookies de sessão
Uma sessão geralmente guarda estado no servidor e entrega ao navegador um session id. Um JWT carrega claims dentro do token, útil entre serviços, mas exige cuidado com expiração, signing keys e conteúdo do payload.
Checklist de assinatura JWT e alg
Um JWT que pode ser decodificado não é automaticamente confiável. A verificação real deve fixar algoritmo, fonte da chave, issuer, audience e política de signature.
- Não escolha o algoritmo de verificação apenas pelo header alg do token; servidores devem usar uma allowlist configurada.
- Trate alg=none, confusão HS256/RS256 ou kid apontando para locais externos como configurações de alto risco.
- Esta ferramenta ajuda na inspeção e em HMAC test tokens, mas verificação de produção deve ficar no backend ou auth gateway.
Debug de tempo exp, nbf e iat
Os claims de tempo de um JWT geralmente estão em segundos Unix. Quando a expiração parece errada, cheque primeiro a confusão entre segundos e milissegundos, o desvio de relógio e o fuso horário exibido.
- Se exp é anterior ao epoch atual em segundos, o token expirou; se nbf é posterior a agora, ainda não está ativo.
- Interpretar milissegundos de 13 dígitos como segundos gera uma data muito distante; interpretar segundos de 10 dígitos como milissegundos cai perto de 1970.
- Servidores devem manter NTP sincronizado e permitir pequeno clock skew, mas grace periods longos não devem esconder erros de configuração.