Decodificador de JWT

Escopo: decodifica, não verifica assinatura

Separa as três partes pelo ponto e decodifica header e payload de Base64URL para JSON, sem recalcular a assinatura — isso exigiria a chave secreta (HS256) ou a chave pública (RS256) do emissor, e nenhuma ferramenta de terceiros deveria pedir esse segredo. Todo o processamento roda no navegador; nenhuma parte do token é enviada a um servidor.

Claims comuns no payload

• iss — emissor do token
• sub — identificador do usuário/entidade (subject)
• aud — audiência/destinatário pretendido
• exp — timestamp de expiração
• iat — timestamp de emissão
• nbf — não válido antes deste timestamp

Os campos de data conhecidos (exp, iat, nbf) são convertidos automaticamente para o formato local. Como header e payload são apenas codificados (não criptografados), qualquer um com o token consegue lê-los — evite incluir dados sensíveis no payload ou compartilhar tokens de produção.

As três partes do token

Um JWS — o formato de JWT que se vê no dia a dia — tem três blocos separados por ponto:

• Header — JSON com o algoritmo (alg) e o tipo (typ). Pode trazer também kid, o identificador da chave usada, útil quando o emissor rotaciona chaves.
• Payload — JSON com as claims: dados sobre a autenticação e sobre o usuário.
• Assinatura — o resultado de assinar os dois primeiros blocos com a chave do emissor. É o que garante que o token não foi adulterado.

Os três blocos são codificados em Base64URL, uma variante do Base64 que troca + e / por - e _ e dispensa o preenchimento com =, para que o token possa trafegar em URLs sem escape adicional. Para decodificar strings Base64 comuns, use o conversor de Base64.

Codificação não é criptografia. Qualquer pessoa com o token lê o payload inteiro — é por isso que colocar CPF, e-mail, telefone ou qualquer dado sensível ali é um problema, ainda que o tráfego seja HTTPS. O token costuma ficar guardado no navegador, aparece em logs e é enviado a cada requisição.

Depurando os erros mais comuns

A maior parte dos problemas de autenticação com JWT se resolve olhando três claims:

• exp — token expirado. A causa número um de 401 inesperado. Compare o horário convertido com o momento da requisição. Se a diferença for pequena e errática, suspeite de relógio dessincronizado entre os servidores — a maioria das bibliotecas aceita uma tolerância configurável para isso.
• aud — audiência errada. O token foi emitido para outro serviço. Comum quando vários microsserviços compartilham o mesmo emissor e um deles valida a audiência com rigor.
• iss — emissor divergente. Típico de ambiente trocado: um token de homologação enviado para produção, ou vice-versa.

Se as três claims estão corretas e a validação ainda falha, o problema está na assinatura — chave errada, algoritmo diferente do esperado ou kid apontando para uma chave já rotacionada.

Por que esta ferramenta não verifica a assinatura

Verificar exigiria a chave secreta, no caso de HS256, ou a chave pública do emissor, no caso de RS256 e ES256. Nenhuma ferramenta de terceiros deveria pedir o segredo de assinatura da sua aplicação — quem tem essa chave consegue forjar tokens válidos para qualquer usuário.

Vale registrar uma vulnerabilidade clássica relacionada: o algoritmo none. A especificação prevê tokens sem assinatura, e implementações antigas aceitavam um token cujo header declarava "alg": "none", permitindo que qualquer um forjasse credenciais. A defesa é o servidor fixar o algoritmo esperado em vez de confiar no que o header informa. Se você encontrar none ao decodificar um token de produção, é um achado grave.

Todo o processamento aqui roda no navegador e nenhuma parte do token é enviada pela rede. Ainda assim, a prática recomendada é usar tokens de teste ao depurar — um token de produção colado em qualquer lugar é um token que passou por um canal a mais do que precisava.