Ferramentas de desenvolvedor · Decodificador JWT
Como decodificar uma carga útil JWT manualmente com base64 e jq
· Como funciona
jwt linha de comando fluxo de trabalho do desenvolvedor
Em uma caixa sem cabeça você ainda pode ler um token com cut, tr, base64 e jq. Esta postagem fornece os comandos, explica a conversão base64url que cada um realiza e lista as armadilhas.
Lendo um token em SSH — quando um navegador não é uma opção
Um servidor headless pode deixar você com uma string em forma de token e sem interface de usuário do navegador. O trabalho de inspeção necessário ainda é pequeno: isolar um segmento, traduzir a ortografia do URL base64, restaurar o preenchimento, decodificar bytes e analisar JSON. O perigo é operacional e não computacional porque o histórico do shell pode preservar uma credencial ativa.
Use um token expirado ou sintético sempre que possível. Se a resposta a incidentes exigir o exame de um valor real, siga os controles de tratamento de credenciais da sua organização, evite que ele entre no histórico ou logs compartilhados e alterne-o após a exposição. A decodificação da linha de comando permanece apenas como inspeção; não fornece chave de verificação ou política de confiança.
Divisão em pontos – corte ou awk para isolar o segmento de carga útil
Um JWT compacto em forma de JWS possui três campos separados por pontos. A carga útil é a segunda. Um shell pode dividi-lo com uma ferramenta compatível com delimitadores, mas citar variáveis para que o shell não expanda caracteres ou divida espaços em branco. Remova um rótulo `Bearer ` inicial antes de selecionar os campos porque esse prefixo pertence à sintaxe HTTP.
Conte os campos em vez de pegar cegamente o campo dois. ToolAcre rejeita qualquer coisa que não seja três partes e identifica separadamente a entrada criptografada em cinco partes. Um pipeline shell deve aplicar o mesmo cuidado estrutural; receber um segmento de entrada malformada pode produzir JSON plausível enquanto oculta que o token original foi truncado.
Convertendo o alfabeto - tr para transformar o hífen e o sublinhado novamente em mais e barra
Implementações de linha de comando padrão Base64 geralmente esperam mais e barra onde um segmento JWT pode conter hífen e sublinhado. A tradução de `-` para `+` e `_` para `/` mapeia os símbolos seguros URL de volta às suas posições padrão sem alterar os valores de seis bits representados.
Use um comando de tradução cuja análise de opções não possa confundir um hífen inicial com um sinalizador e mantenha os dados em uma variável entre aspas ou entrada padrão. A conversão do alfabeto é um trabalho de codificação reversível. Ele não descriptografa as declarações e o sucesso não estabelece que o token veio do emissor nomeado.
Restaurando o preenchimento — a aritmética que adiciona o número certo de sinais de igual
Após a tradução, calcule o comprimento módulo quatro. O resto zero não precisa de sinais de igual, o resto dois precisa de dois e o resto três precisa de um. O restante indica truncamento e deve interromper o pipeline. Acrescentar preenchimento arbitrário até que um utilitário pare de reclamar pode ocultar o dano em vez de diagnosticá-lo.
ToolAcre usa exatamente esta regra de comprimento em `base64ToBytes` e rejeita o resto impossível. Os utilitários do shell variam quanto à aceitação do preenchimento omitido, portanto, normalizar a entrada primeiro torna o conceito do pipeline explícito e portátil, embora os sinalizadores de comando ainda possam diferir entre os sistemas operacionais.
Decodificação e impressão bonita - base64 -d canalizado para jq
Canalize o valor preenchido para o decodificador Base64 da plataforma e depois para `jq`. O primeiro comando recupera bytes; o segundo requer que esses bytes formem JSON. Um comando Base64 bem-sucedido seguido por um erro de análise jq significa que a codificação era estruturalmente decodificável, mas seu conteúdo não era uma carga útil JSON.
Essa distinção reflete os caminhos de erro de ToolAcre. Ele primeiro relata base64url ou UTF-8 inválido, depois relata separadamente JSON inválido e, em seguida, rejeita nulos, matrizes e primitivos porque um cabeçalho ou carga útil JWT deve ser um objeto para esta ferramenta. Manter os estágios separados torna uma falha acionável.
Exemplo resolvido — o pipeline completo em um token de amostra, com a saída em cada estágio
Para um exemplo sintético, o segmento de carga útil `eyJzdWIiOiJkZW1vIiwicm9sZSI6InJlYWRlciJ9` não precisa de tradução alfabética ou preenchimento. A decodificação produz `{"sub":"demo","role":"reader"}` e jq formata esse objeto entre linhas. A função visível é apenas uma string fornecida pelo token.
Agora altere o JSON, codifique-o novamente e anexe qualquer terceiro segmento. O pipeline ainda imprime o objeto alterado. Isto prova por que um comando de decodificação não pode servir como verificação de validade: tanto as declarações legítimas quanto as fabricadas atravessam as mesmas transformações públicas, a menos que um verificador separado verifique a assinatura.
Armadilhas - histórico do shell capturando o token, implementações base64 que rejeitam preenchimento ausente e tokens com um 'Bearer' inicial
Falhas comuns incluem manter o prefixo HTTP, selecionar o campo errado separado por pontos, perder caracteres finais durante a cópia e usar uma implementação Base64 que requer preenchimento. Outra armadilha é colocar o token inteiro diretamente na linha de comando, onde as listagens de processos ou o histórico podem retê-lo.
Prefira entradas padrão e variáveis efêmeras sob controles apropriados e nunca cole um token de produção em chats, tickets ou terminais compartilhados por conveniência. Lembre-se também de que o terceiro segmento é material de assinatura binária em vez de JSON, portanto, enviá-lo por meio de jq deve falhar e não informa nada sobre a validade da assinatura.
Conclusão: a mesma decodificação, em qualquer ambiente — quando você tem um navegador, o decodificador ToolAcre JWT faz isso localmente sem nada carregado
O pipeline do shell e ToolAcre executam a mesma sequência somente de decodificação em ambientes diferentes: dividir, normalizar, preencher, decodificar UTF-8 e analisar JSON. Use qualquer ambiente que você possa inspecionar e controlar, com dados não confidenciais como padrão.
Nenhum dos caminhos verifica a autenticidade ou autoriza um chamador. Depois de ler o formato da carga útil, vá para o verificador confiável e os registros do serviço para tomar decisões criptográficas e políticas. Um comando que produz bastante JSON concluiu uma tarefa de formatação, não um julgamento de segurança.