Codificador / decodificador JWT

O que significa « decodificar um JWT »?

Decodificar um JWT (« jwt decode », « decode jwt online ») consiste em cortar a string nos dois pontos e depois decodificar cada segmento em Base64URL para recuperar o JSON original. Nenhuma chave é necessária: o cabeçalho e o payload são simplesmente codificados, não cifrados. É exatamente a intenção por trás de « jwt payload decoder » ou « decode jwt without verify » — ver o que o token contém, sem afirmar que ele é autêntico.

Atenção para distinguir bem as duas ações. Ler um JWT não prova nada: qualquer pessoa pode fabricar um token com payload atraente e assiná-lo com o próprio segredo. Verificar a assinatura prova que o conteúdo não foi modificado por terceiros. Um decodificador que mostra « admin: true » sem controle de assinatura conta uma história, não um fato.

Os três segmentos de um JWT

A string se divide exatamente em três partes separadas por pontos: header.payload.signature. O cabeçalho contém no mínimo alg e typ, às vezes kid para indicar qual chave foi usada. O payload contém os claims, esses pares chave-valor cujo registro é mantido pela IANA. A assinatura cobre os dois primeiros segmentos concatenados exatamente como estão escritos — a menor alteração de um espaço ou de um caractere quebra a comparação.

Toda a dificuldade vem do fato de esses segmentos estarem em Base64URL e não em Base64: o sinal de mais vira um hífen, a barra vira um sublinhado, e o preenchimento = desaparece. Um decodificador Base64 clássico falhará, portanto, em um JWT válido. A tabela « Base64URL versus Base64 clássico » da aba de referência mostra exatamente essas substituições.

Como verificar uma assinatura: HS256, RS256, ES256

Para um algoritmo HMAC — HS256, HS384, HS512 — o mesmo segredo serve para assinar e verificar: a ferramenta recalcula HMAC(secret, base64url(header) + "." + base64url(payload)) e compara o resultado com a assinatura transportada. É o caso mais comum, e também o mais perigoso: qualquer serviço que detenha o segredo pode emitir um token. Um segredo com menos de 32 bytes, reutilizado entre ambientes, basta para comprometer toda a cadeia.

Para os algoritmos assimétricos — RS256, RS384, RS512, ES256, ES384, ES512, PS256 — você só precisa da chave pública para verificar, o que permite conferir um token emitido por terceiros sem nunca compartilhar o segredo de assinatura. Cole a chave no formato PEM -----BEGIN PUBLIC KEY----- (SPKI); o resultado bruto de uma exportação OpenSSL é diretamente utilizável. Para ES256, a assinatura está no formato r||s bruto, aquele que o WebCrypto espera.

Por fim, desconfie doalg confusion : se o seu serviço espera RS256 mas aceita um token cujo cabeçalho declara HS256, um atacante assinará com a chave pública — virada em chave HMAC — e passará na verificação. Fixe o algoritmo esperado do lado do servidor, nunca leia o próprio token.

exp, iat, nbf: os carimbos de tempo que armadilham

Esses três claims são segundos Unix, sem milissegundo e sem fuso horário: iat 1516239022 significa 2018-01-17T21:30:22Z. Dois erros voltam sempre: comparar com uma data em milissegundos (valor dez mil vezes maior) e interpretar um timestamp como local em vez de UTC. A aba « Expiração » converte nos dois sentidos, mostra o ISO 8601, a data local e o tempo restante ou decorrido — dá para detectar na hora um token « já expirado » ao segundo de relógio.

Alongar o tempo de vida não eleva o nível de segurança: um exp empurrado muda o valor exibido, não a assinatura. Se você precisar reemitir, assine novamente o token com o segredo ou a chave privada — é exatamente o papel da aba « Codificar ».

Base64URL: por que os decodificadores clássicos falham

Base64URL (RFC 4648 §5) usa o alfabeto A-Z a-z 0-9 - _ e não admite preenchimento. Um payload de 20 caracteres costuma gerar um comprimento não múltiplo de quatro após a remoção do = : é normal, não é corrupção. Os caracteres - e _ são ambíguos para o olho humano, o que explica metade dos « tokens quebrados » relatados. Nosso decodificador aceita os dois alfabetos, maiúsculas e minúsculas misturadas, preenchimento opcional e um prefixo Bearer.

Segurança: o que um JWT não faz

Um JWT não oferece nem confidencialidade nem revogação. O payload é legível por todos: nunca coloque e-mail, papel interno ou dado pessoal que você não aceitaria enviar em texto puro. E um token assinado continua válido até exp mesmo depois de sair — é preciso uma lista de revogação, um jti acompanhamento do lado do servidor, ou tempos de vida curtos com refresh token. Um bom reflexo: exp curto (10 a 15 minutos), iat controlado, nbf alinhado com iat, aud e iss verificados no recebimento.

Recomendado para

Desenvolvedores back-end e front-end (OAuth 2.0, OpenID Connect, API REST), integradores e DevOps (infraestrutura de identidade, JWKS, rotação de chaves), testadores e pentesters (reescrever claims, alg confusion, expiração), administradores de sistemas (depurar um 401 inexplicável), estudantes (entender Base64URL e WebCrypto), e qualquer pessoa que precise de um decodificador JWT online rápido, completo e confidencial — complementado pelocodificador decodificador Base64, pelocodificador decodificador URL e pelo formatador JSON.

Decodificador JWT 100 % local: seu token nunca sai do seu computador

Diferentemente dos decodificadores JWT online clássicos, nenhuma string é transmitida: a decodificação, a verificação de assinatura e a codificação são executadas inteiramente no seu navegador via WebCrypto, sem biblioteca de terceiros nem requisição de rede. É isso que permite inspecionar um token de sessão real, uma chave de staging ou um token de serviço interno sem risco, mesmo offline ou em uma rede pública. O histórico e a última entrada são mantidos localmente (localStorage) e permanecem no seu dispositivo.

A licença Premium Volade acrescenta uma sincronização na nuvem opcional, criptografada, independente da ferramenta — o resto continua gratuito e ilimitado, sem cadastro.