Decodificador de JWT

Como usar

1. Cole o token no campo Token JWT. Pode colar do jeito que veio: com Bearer na frente, entre aspas, quebrado em várias linhas ou até no meio de uma resposta JSON, de um cookie ou de uma URL (o token é encontrado no texto).
2. O token aparece colorido por parte (cabeçalho, conteúdo e assinatura) e, ao lado, o cabeçalho e o conteúdo decodificados, em JSON formatado.
3. Na lista de claims, cada campo vem com uma explicação curta. Datas como exp, iat e nbf aparecem no seu fuso horário, em UTC e em tempo relativo ("expira em 2 horas").
4. Para conferir a autenticidade de um token HS256, HS384 ou HS512, digite o segredo em Verificar assinatura. Não tem um token à mão? Toque em Exemplo: o segredo do exemplo aparece logo abaixo do campo.

O que é um JWT

JWT (JSON Web Token) é um formato compacto para transportar informações entre sistemas, muito usado em login e APIs. Ele tem três partes separadas por ponto:

• Cabeçalho: diz qual algoritmo assinou o token (alg) e, às vezes, qual chave (kid).
• Conteúdo (payload): as informações em si, chamadas de claims: quem é o usuário, para qual sistema o token vale, até quando.
• Assinatura: um código calculado sobre as duas primeiras partes. Se alguém mudar uma vírgula do conteúdo, a assinatura deixa de bater.

Cabeçalho e conteúdo são JSON codificado em base64url, uma variação do base64 que troca + e / por - e _ e dispensa o = no final, para caber em URLs e cabeçalhos HTTP. Por isso todo JWT começa com eyJ: é o {" do JSON codificado.

As claims mais comuns

• iss (emissor): quem gerou o token, como o servidor de login.
• sub (assunto): a quem o token se refere, geralmente o ID do usuário.
• aud (público): para qual aplicativo ou API ele foi emitido.
• exp (expiração), nbf (não antes de) e iat (emitido em): datas em segundos desde 1º de janeiro de 1970, em UTC (o chamado Unix time). Um token com exp no passado já não deve ser aceito; com nbf no futuro, ainda não.

Provedores de identidade acrescentam outras, como email, roles, scope e sid. Campos que a ferramenta não reconhece aparecem como claims personalizadas.

Decodificar não é verificar

Qualquer pessoa consegue ler um JWT: o conteúdo não é criptografado, só codificado. A ferramenta mostra o que está escrito, mas isso não prova que o token é legítimo. Quem garante a origem é a assinatura, e quem decide se aceita o token é o servidor, depois de verificá-la.

Daí a regra mais importante: nunca coloque segredos no payload, como senhas, números de documentos ou chaves de API. Se a informação precisa ficar oculta, o formato certo é o JWE (token criptografado, com cinco partes), que a ferramenta reconhece e explica.

HS256 ou RS256?

• HS256 (e HS384/HS512) usa um segredo compartilhado: o mesmo segredo assina e verifica. É simples, mas todo serviço que verifica também conseguiria emitir tokens. É o caso que esta página verifica.
• RS256 (e ES256, PS256, EdDSA) usa um par de chaves: a chave privada, guardada só pelo emissor, assina; a chave pública, que pode ser divulgada, verifica. É o padrão de provedores de login como Google, Microsoft e Auth0. Para verificar esses tokens, use a biblioteca JWT do seu servidor com a chave pública do provedor.

Erros comuns

• alg: none: token sem assinatura. Servidores nunca devem aceitá-lo; algumas bibliotecas antigas aceitavam, e isso virou uma falha clássica de segurança.
• Milissegundos no lugar de segundos: usar Date.now() do JavaScript gera exp mil vezes maior, e o token "vale" por milhares de anos. A ferramenta avisa quando o número parece estar em milissegundos.
• Relógios dessincronizados: se o servidor que emite está adiantado, o token pode chegar com iat ou nbf no futuro e ser recusado. Bibliotecas costumam aceitar uma folga de alguns segundos.
• Token sem exp ou com validade muito longa: se vazar, continua funcionando. Prefira tokens de acesso curtos (minutos) e renovação com um refresh token.
• Guardar o token no localStorage: qualquer script que rode na página (inclusive um injetado por falha de XSS) consegue lê-lo. Cookies HttpOnly e Secure reduzem esse risco.

Privacidade

Tudo acontece no seu navegador: o token e o segredo não são enviados a nenhum servidor, não ficam salvos e somem ao fechar a página. A verificação usa a criptografia nativa do navegador (Web Crypto), que exige página segura (HTTPS). Mesmo assim, trate tokens de produção como senhas: depois de testar, prefira revogá-los ou deixá-los expirar.