Decodificador de JWT
Leia o cabeçalho e as claims de um token e veja o que ele diz sobre si mesmo. Decodificação, não verificação.
Descodificar não é verificar. Os dois segmentos legíveis de um JWT são apenas base64 — qualquer pessoa os lê e qualquer pessoa os escreve. É só a assinatura que torna um token digno de confiança, e verificá-la exige a chave. Esta página não tem a chave, não a pede, e não afirma nada sobre se o token é genuíno.
Um prefixo “Bearer” é removido automaticamente. Nada do que colar sai desta página.
Três segmentos, e só um interessa
Um JWT são três cadeias em base64url unidas por pontos. As duas primeiras são JSON que consegue ler; a terceira é uma assinatura sobre as duas primeiras.
eyJhbGciOiJIUzI1NiJ9 . eyJzdWIiOiIxMjM0In0 . 4fXK...
header payload signatureO cabeçalho diz que algoritmo o assinou. A carga transporta as reivindicações. Nenhum dos dois está cifrado — o base64 é codificação de transporte, não ocultação, e quem tiver o token lê ambos em cerca de um segundo.
A assinatura é a única parte a fazer trabalho de segurança. Prova que os dois primeiros segmentos foram produzidos por alguém com a chave de assinatura e não foram modificados desde então. Sem a verificar, um JWT é um ficheiro de texto que se descreve a si próprio, sem mais autoridade do que qualquer outra cadeia que um cliente lhe tenha enviado.
É por isso que esta página não lhe dirá que um token é válido
A verificação precisa da chave, e não há nenhuma versão de «cole o seu segredo de assinatura numa página web» que seja um bom conselho. O que a ferramenta faz em vez disso é reportar o que o token diz sobre si mesmo: se expirou, se já chegou o seu instante de início, se o algoritmo é simétrico ou assimétrico, e se ele afirma não precisar de assinatura nenhuma.
alg:none, e porque é um caso instrutivo
A especificação permite "alg": "none" — um token sem assinatura. O ataque escreve-se sozinho: pegue num token legítimo, edite a carga para reivindicar o que quiser, ponha o algoritmo a none, apague a assinatura e envie.
Uma biblioteca que leia o algoritmo do cabeçalho e faça o que lá diz vai aceitar isto. Foi o atacante que escolheu a política de verificação, porque a política estava na parte da mensagem controlada por ele.
A variante próxima é a confusão de algoritmos. Um servidor que verifica RS256 tem a chave pública, que não é secreta. Mude o cabeçalho para HS256 — um algoritmo simétrico — e assine com essa chave pública como segredo partilhado. Uma biblioteca ingénua usa o mesmo material de chave para ambos e o token forjado passa na verificação.
Os dois resolvem-se da mesma maneira, e é um princípio geral que vale a pena levar para outros lados: quem verifica tem de declarar que algoritmos aceita, em vez de perguntar ao token.
O que corre mesmo mal em produção
| Sintoma | Causa habitual |
|---|---|
| Rejeitado logo a seguir à emissão | Desvio de relógio. O iat ou o nbf estão uns segundos à frente do relógio de quem verifica. Permita uma pequena tolerância. |
| Funciona localmente, falha em produção | Chave de assinatura diferente por ambiente — um token de pré-produção enviado para produção. |
| Assinatura válida, na mesma rejeitado | A reivindicação aud ou iss não corresponde ao que aquele serviço espera. |
| Funciona e depois pára a meio da sessão | Expiração. Os tokens de vida curta precisam de um fluxo de renovação, e costuma ser essa a peça em falta. |
| Os pedidos falham por cabeçalhos demasiado grandes | O token cresceu além do limite. A maioria dos servidores limita os cabeçalhos a cerca de 8 KB, e os navegadores limitam um cookie a 4 KB. |
O problema da revogação
A razão para usar um JWT é que a verificação não precisa de ir à base de dados — o token transporta a sua própria prova. É exactamente por isso que não o consegue revogar. Nada é consultado no momento da verificação, portanto não há onde registar que um token deve deixar de funcionar.
As opções, e nenhuma é grátis:
- Expiração curta mais tokens de renovação. A resposta padrão. Os tokens de acesso vivem minutos, os de renovação são verificados contra uma base de dados e podem ser revogados.
- Uma lista de revogados. Verificar o
jtide cada token contra um repositório dos revogados — o que traz de volta a consulta que o formato existia para evitar. - Rodar a chave de assinatura. Invalida todos os tokens de uma vez, incluindo os de toda a gente.
Se precisa mais de revogar sessões individuais de imediato do que de verificação sem estado, um identificador de sessão opaco apoiado num repositório é o desenho mais simples — e é subvalorizado.
Relacionado
Os três segmentos são Base64 seguro para URL, sem enchimento — e é por isso que um segmento falha tantas vezes num descodificador estrito. Descodificadas, as duas partes legíveis são JSON. E para as credenciais que o token substitui, o verificador de robustez cobre a outra ponta do início de sessão.
Perguntas sobre JWT
Descodificar um JWT verifica-o?
Não, e a distinção é todo o modelo de segurança. O cabeçalho e a carga estão em base64url — lê-los não exige nada. Verificar significa recalcular a assinatura com a chave e comparar, o que prova que o token foi emitido por quem detém essa chave e não foi alterado desde então. Um descodificador sem a chave diz-lhe o que um token afirma; só a verificação lhe diz se deve acreditar.
É seguro colar um token real num sítio da internet?
Nesta página, sim — a descodificação acontece no seu navegador e nada é transmitido. Mas o instinto por trás da pergunta é bom e vale a pena mantê-lo. Um JWT costuma ser uma credencial viva: quem o tiver pode agir em seu nome até expirar. A um descodificador que o envie para um servidor foi entregue uma sessão a funcionar. Verifique onde é que cada ferramenta faz o trabalho antes de lhe colar um token de produção.
Posso pôr segredos na carga de um JWT?
Não. A carga é assinada, não cifrada — é legível por quem tiver o token, incluindo o utilizador a quem foi emitido. Assinar garante que o conteúdo não foi alterado; não esconde nada. Se precisa mesmo de uma carga confidencial, isso é JWE, uma especificação diferente e bastante mais trabalhosa. Na prática, a melhor resposta costuma ser guardar a parte sensível no servidor e pôr um identificador no token.
O que é a vulnerabilidade alg:none?
A especificação JWT permite um «alg» igual a «none», ou seja, um token sem assinatura. O ataque consiste em pegar num token válido, alterar a carga para reivindicar privilégios de administrador, pôr alg a none e retirar a assinatura. Uma biblioteca que confie no campo de algoritmo do cabeçalho valida-o — o próprio token declarou que não era preciso verificar nada. Todas as bibliotecas importantes foram corrigidas, mas a lição generaliza-se: quem decide que algoritmos aceita tem de ser o servidor, não o token.
Como revogo um JWT antes de expirar?
Em larga medida não consegue, e é essa a troca que o formato faz. Um JWT é verificável sem ir à base de dados, o que é justamente o que o torna rápido — e é também por isso que nada do que é consultado no momento da verificação sabe que o quis revogar. As respostas viáveis são prazos curtos com tokens de renovação, uma lista de identificadores revogados consultada a cada pedido (o que traz de volta a ida à base que estava a evitar), ou rodar a chave de assinatura para invalidar tudo de uma vez.
Porque é que o meu token está a ser rejeitado se parece válido?
Fora a expiração, as causas habituais são o desvio de relógio entre o emissor e o verificador, uma reivindicação de audiência ou de emissor que não corresponde ao que o servidor espera, ou o token ter sido assinado com uma chave diferente da que o verificador tem — muitas vezes um token de pré-produção usado contra a produção. O descodificador acima assinala os problemas de tempo que consegue ver; as divergências de audiência e de chave só o servidor lhas pode dizer.
Última revisão . Encontrou algo desactualizado? Diga-nos.