Decodificador de JWT

O que um JWT realmente é

Um JSON Web Token (RFC 7519) é três segmentos codificados em Base64URL unidos por pontos:

<header>.<payload>.<signature>

Os dois primeiros segmentos são objetos JSON. O terceiro é uma assinatura binária que prova que os dois primeiros vieram de alguém que tem a chave de assinatura do emissor. Qualquer pessoa pode jogar um JWT em um decodificador — incluindo este — e ler o header e payload. Apenas alguém com a chave de verificação pode confirmar a assinatura.

Trate JWTs decodificados como entrada do usuário não confiável a menos que você também tenha verificado a assinatura. Esta ferramenta apenas decodifica — por design nós não pedimos chaves, porque colar seu segredo HMAC de produção em um site aleatório é um pesadelo de segurança.

O que vai no header

Tipicamente dois campos:

• alg — o algoritmo de assinatura (HS256, RS256, ES256, etc.).
• typ — geralmente "JWT".

Às vezes você verá kid (ID de chave) quando o emissor rotaciona chaves, ou x5t quando certificados X.509 estão envolvidos. Qualquer outra coisa é específica de implementação.

O que vai no payload (os claims)

O payload é apenas um objeto. RFC 7519 reserva alguns nomes de campo com significados padrão:

Além desses, emissores adicionam claims personalizados livremente: IDs de usuário, roles, nível de plano, qualquer coisa. Esta ferramenta destaca os padrão e mostra status de expiração em primeiro plano.

O desastre alg=none

Historicamente, bibliotecas JWT aceitavam tokens com "alg": "none" e os tratavam como autenticados. Combinado com o fato de que qualquer um pode criar um header, isso significava que atacantes podiam forjar tokens que burlavam verificação inteiramente.

Bibliotecas modernas rejeitam none por padrão, mas a lição permanece: sempre verifique com o algoritmo esperado explicitamente, nunca confie no algoritmo declarado dentro do header. Se sua biblioteca tem uma opção algorithms: ['RS256'], defina.

HS256 vs RS256

HS256 é simétrico — o mesmo segredo assina e verifica. Rápido, simples, mas o verificador deve ter o segredo, o que significa que também pode forjar tokens. Use para serviços de primeira parte que se confiam plenamente.

RS256 (e ES256) é assimétrico — uma chave privada assina, uma chave pública verifica. Verificadores apenas recebem a chave pública, portanto não conseguem forjar. Use para tokens cruzando limites de confiança (APIs de terceiros, serviços distribuídos).

Casos de uso comuns

• Tokens de autenticação emitidos após login (geralmente via OAuth2 / OIDC).
• Tokens de acesso API para chamadas de serviço-para-serviço stateless.
• Magic links para login por e-mail sem senha.
• Email verification e fluxos password reset.
• Webhook signatures (menos comum; HMAC simples é mais típico).

Privacidade nesta página

A ferramenta decodifica no seu navegador via Base64URL + JSON.parse. Nós não salvamos seu token, não registramos solicitações e não temos um endpoint de servidor para enviá-lo. Abra DevTools Network e observe — zero tráfego.

Se seu token contém segredos reais de produção, prefira decodificar localmente com um CLI como jq. Decodificadores públicos (este incluído) são convenientes mas não apropriados para credenciais ao vivo.

Ferramentas relacionadas

• Base64 Encode — veja como cada segmento se parece antes/depois.
• Hash Generator — calcule HMAC manualmente para verificação HS256.

É seguro colar um JWT em um decodificador?

Decodificar o header e payload é seguro no sentido de que foram já projetados para serem legíveis. Mas se o token concede acesso a qualquer coisa real, trate o ato de colá-lo em uma ferramenta de terceiros como um vazamento de credencial — assuma que o operador da ferramenta (ou qualquer pessoa com acesso à rede entre você e eles) agora o tem. Decodifique tokens de produção localmente com jq ou seu IDE em vez disso.

Por que esta ferramenta não verifica a assinatura?

Para verificar, precisaríamos de sua chave de assinatura (HS256) ou chave pública (RS256). Solicitar chaves em uma ferramenta de navegador seria uma gigantesca bandeira vermelha. Verificação pertence no seu código de aplicação usando uma biblioteca verificada, não em uma página web pública.

Por que meu token tem caracteres =?

Não tem — JWT usa Base64URL, que remove preenchimento. Se você vê =, o token foi provavelmente re-codificado em algum lugar como Base64 padrão. A maioria dos decodificadores (este incluído) tolera isso, mas JWT em conformidade com spec não deveria ter.

Qual é a vulnerabilidade alg=none?

Bibliotecas mais antigas aceitavam tokens onde o header declarava "alg": "none" e pulavam verificação de assinatura inteiramente. Atacantes exploravam isso forjando payloads arbitrários. O conserto é validar com uma lista explícita de algoritmo permitido em seu verificador — nunca confie no campo alg no header.

HS256 ou RS256?

Simétrico (HS256) quando ambos os lados se confiam plenamente um ao outro e podem compartilhar um segredo. Assimétrico (RS256/ES256) quando você não quer que verificadores sejam capazes de forjar tokens, ou quando as chaves cruzam um limite de confiança.

Como revogar um JWT?

Você não consegue, não diretamente — JWTs são stateless. Workarounds: manter tokens curta vida e usar tokens de atualização; manter uma lista de bloqueio lado do servidor com chave por jti; ou usar tokens opacos com sessões lado do servidor em vez de JWT.

Qual é a diferença entre exp e nbf?

exp é a última vez que o token é válido (após isso ele expira). nbf é a primeira vez que é válido (antes disso não deveria ser aceito). Ambos são Unix timestamps em segundos. iat é quando o token foi emitido — informacional.