JWT é apenas Base64 em um casaco — Decodifique online em segundos

Você está olhando para uma aba de rede. Há um cabeçalho de requisição que diz Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c e sua primeira reação é: "O que diabos é isso?"

Boa notícia: a maioria dessa string é apenas Base64. O bloco assustador está usando um casaco de trench, fingindo ser mais misterioso do que realmente é. Vamos tirar esse casaco.

O que é realmente um JWT

Um JSON Web Token é três pedaços codificados em Base64url unidos por pontos:

• Cabeçalho – algoritmo e tipo de token (por exemplo, {"alg":"HS256","typ":"JWT"})
• Carga útil – as declarações: ID do usuário, papéis, validade, qualquer coisa que o servidor decidiu incluir
• Assinatura – a parte que realmente garante segurança

Os cabeçalhos e o corpo da mensagem são não criptografados. Eles são codificados em Base64url, o que significa que qualquer pessoa com o token pode lê-los — sem necessidade de chave. A assinatura é a única coisa que previne alterações: mudar um caractere no corpo invalida o token.

Para decodificar o corpo agora: pegue o segundo pedaço (entre os dois pontos), coloque em um decodificador de Base64e você verá um JSON simples. Isso é tudo. É o truque mágico.

Como decodificar um JWT em segundos

A forma mais rápida: cole seu token no decodificador de JWT no IOTools. Ele divide as três partes, decodifica cada uma e exibe o cabeçalho e o corpo como JSON formatado — sem conta, sem configuração, sem “entrar para desbloquear o decodificador”.

O que você verá imediatamente em um payload típico:

• sub – assunto (normalmente ID do usuário)
• iat – horário de emissão (em formato de epoch do Unix)
• exp – horário de validade
• iss – emissor
• Qualquer declaração personalizada que seu API colocar: papéis, permissões, nível do plano, etc.

Se você só precisa saber se um token expirou sem configurar um decodificador completo, o verificador de expiração do JWT lê a exp declaração e diz exatamente quanto tempo resta — ou quando morreu.

Os Três Erros que Queimam Desenvolvedores

1. A Validade que Você Esqueceu de Verificar

O exp O campo é apenas um número no corpo — o servidor deveria validá-lo, mas muitos códigos antigos não fazem isso, ou têm um erro no tratamento de fuso horário. Se os usuários estão sendo deslogados de forma misteriosa (ou estão sendo mantidos logados para sempre), decodifique o token e compare exp com a marcação atual do Unix. O verificador de validade faz isso em um clique.

2. Confusão com o Algoritmo

O campo do cabeçalho indica ao verificador qual algoritmo usar. Algumas bibliotecas antigas de JWT aceitavam alg e ignoravam a verificação completamente — removendo a assinatura e tratando qualquer corpo como válido. Isso é um ataque conhecido. Sempre verifique que sua biblioteca impõe uma lista específica de algoritmos e rejeita {"alg":"none"} Outra variante: RS256 (assimétrico) vs HS256 (simétrico). Um atacante que conhece sua chave pública pode criar um token trocando o cabeçalho para none.

e assinando com a chave pública como segredo — se a biblioteca acredita de forma ingênua no campo HS256 da declaração. A solução: configure sua biblioteca com um algoritmo explícito, e não com “qualquer coisa que o token diga”. alg 3. Segredos no Corpo do Token

Como o corpo é codificado em Base64 e não criptografado, qualquer coisa que você colocar lá é lida pelo cliente (e por qualquer pessoa que interceptar o token por HTTP puro, embora você esteja usando HTTPS em todos os lugares, certo?). Não coloque senhas, dados pessoais (PII) ou detalhes internos no corpo do JWT. O corpo é para metadados de autorização — não um local para armazenar dados sensíveis.

Decodifique um token de seu próprio app e veja o que está lá. Você pode se surpreender com o que um desenvolvedor anterior colocou há anos.

JWT vs Tokens de Sessão: O Que É Realmente Diferente

A discussão perene. Aqui está uma comparação direta:

JWT

	Token de Sessão	Onde a state está
Dentro do token (sem estado)	No lado do servidor (banco de dados ou memória)	Revogação
Difícil — o token é válido até	a menos que você mantenha uma lista bloqueada exp Fácil — apague o registro da sessão	Boa para sistemas distribuídos; não é necessário um armazenamento compartilhado de sessão
Escalabilidade	Requer sessões fixas ou armazenamento compartilhado (Redis, etc.)	Visibilidade do corpo
O cliente pode ler as declarações (não criptografadas)	Opcional para o cliente	Risco de armazenamento
localStorage é vulnerável a XSS; cookie httpOnly é mais seguro	cookie httpOnly (abordagem padrão)	Tamanho do token
Mais grande — carrega todas as declarações inline	Pequeno — apenas um ID	Melhor para
APIs, microserviços, autenticação cross-domain	Aplicações web tradicionais com renderização no servidor	Nem um dos dois é universalmente melhor. Os JWTs brilham quando você precisa de autenticação sem estado entre múltiplos serviços. Os tokens de sessão são mais simples quando você controla toda a pilha e precisa de revogação imediata (por exemplo, "deslogar em todos os lugares" em um incidente de segurança).

Depurando JWTs em Fluxos Reais

Aqui está a sequência típica quando algo está errado em uma API que usa JWTs:

Copie o token

1. do pedido falhado (cabeçalho de autorização, parâmetro de consulta ou cookie — onde sua API o coloca) Cole no
2. para ver as declarações brutas decodificador de JWT — o token expirou? Use o
3. Verifique exp se você não quiser fazer cálculos de timestamp do Unix na sua cabeça verificador de validade — o emissor e o público correspondem ao que seu serviço espera?
4. Verifique iss e aud Verifique o algoritmo
5. no cabeçalho — ele corresponde à configuração do servidor? Verifique o formato da assinatura
6. — três partes? Duas? Um token adulterado às vezes aparece como duas partes sem assinatura A maioria dos problemas de depuração de JWTs termina na etapa 3. O token foi emitido com TTL curto, foi armazenado em algum lugar e chegou expirado. Isso é comum e tedioso.

A Assinatura: A ÚNICA PARTE QUE IMPORTA

A assinatura é calculada como:

. O servidor gera isso ao emitir o token. Ao validar, ele recalcula o mesmo hash e o compara. Se o corpo foi modificado de alguma forma — mesmo um caractere — o hash não corresponderá e o token será rejeitado. HMACSHA256(base64url(header) + "." + base64url(payload), secret)É por isso que decodificar um JWT para ler as declarações é seguro e simples, mas criar um sem a chave secreta não é possível. O Base64 é o casaco; a assinatura é a fechadura da porta.

Para algoritmos assimétricos (RS256, ES256), a chave de assinatura é uma chave privada que nunca sai do servidor de autenticação. A chave de verificação é uma chave pública que qualquer serviço pode usar — sem necessidade de segredo compartilhado. Isso é a arquitetura correta para microserviços onde múltiplos serviços precisam verificar tokens, mas apenas um deve emitir os mesmos.

JWT é apenas Base64 em um Casaco de Trench — Decodifique Online em Segundos 2

Você também pode gostar