Ferramentas de desenvolvedor · Decodificador JWT
Base64 vs Base64url: Por que um JWT falha em um decodificador Base64 padrão
· Como funciona
jwt base64 codificação
Cole um segmento JWT em um decodificador base64 comum e ele poderá reclamar de caracteres ou preenchimento. Esta postagem explica os mandatos da variante base64url JWS e como converter entre os dois.
Caractere inválido, preenchimento incorreto — os erros que aparecem quando base64 encontra base64url
Uma mensagem de “caractere inválido” ou “preenchimento incorreto” geralmente significa que um segmento JWT foi fornecido a um decodificador que espera Base64 comum. O token pode ser copiado corretamente. Sua representação segue as convenções base64url, enquanto o utilitário receptor aceita um alfabeto relacionado, mas não idêntico, ou insiste em preenchimento explícito.
ToolAcre evita essa incompatibilidade entre o cabeçalho e a carga útil. Seu decodificador de bytes remove espaços em branco, traduz símbolos seguros URL, restaura o preenchimento omitido quando o comprimento permite e, em seguida, converte bytes como UTF-8 estrito. A falha em qualquer estágio torna-se um erro INVALID_JWT em vez de uma exceção bruta do navegador.
Dois alfabetos – mais e barra versus hífen e sublinhado, e por que os URLs forçaram a mudança
O Base64 padrão usa mais e barra para suas duas posições finais do alfabeto. Base64url atribui hífen e sublinhado a essas mesmas posições. Os valores subjacentes de seis bits não mudam, portanto, a tradução de `-` para `+` e `_` para `/` preserva cada byte decodificado; apenas a ortografia segura para transporte muda.
Essas substituições são importantes em canais onde o sinal de mais ou barra já possui sintaxe. Uma ortografia segura URL reduz a interpretação acidental por processamento de formulário ou caminho. Não acrescenta sigilo, integridade ou autenticidade. Qualquer pessoa que receba um segmento pode reverter as substituições e recuperar os mesmos bytes sem chave criptográfica.
Preenchimento — por que JWS remove os sinais de igual e como restaurá-los para um decodificador estrito
ToolAcre aceita preenchimento omitido. Após a normalização do alfabeto, examina o comprimento do segmento módulo quatro. Um resto de dois precisa de dois sinais de igual e um resto de três precisa de um. O restante de um é impossível para um valor Base64 completo e é rejeitado como uma string truncada em vez de ser adivinhado na forma.
A recuperação do preenchimento é uma estrutura mecânica, não um reparo simbólico. Adicionar sinais de igual não pode restaurar caracteres perdidos durante a cópia e a decodificação de bytes bem-sucedida não mostra que os bytes vieram de um emissor. A implementação apenas reconstrói o comprimento canônico exigido pelo decodificador do navegador antes de chamar `atob`.
Decodificando o token inteiro de uma vez – o erro de não dividir os pontos primeiro
Um token assinado compacto deve ser dividido em pontos antes que qualquer segmento seja decodificado. Passar `header.payload.signature` para uma função Base64 introduz pontos que pertencem à serialização JWT, não ao alfabeto Base64. ToolAcre requer exatamente três segmentos para esta entrada em forma de JWS e relata a contagem observada quando essa estrutura está ausente.
O caso de cinco partes recebe uma mensagem JWE separada porque a serialização compacta criptografada não é o mesmo objeto. Em vez disso, duas ou quatro partes sugerem truncamento ou entrada errada. Esta verificação estrutural vem antes da interpretação de JSON, mantendo um erro de cópia distinto de texto codificado malformado ou JSON malformado.
Exemplo resolvido - convertendo um segmento de base64url para base64, preenchendo-o e decodificando-o para JSON
Para uma conversão bem-sucedida, use `eyJhbGciOiJIUzI1NiJ9`. Ele não contém caracteres alfabéticos que difiram entre as variantes, mas o preenchimento ausente ainda ilustra o pipeline. Seu comprimento permite a restauração do estofamento; a decodificação produz UTF-8 bytes para `{"alg":"HS256"}`, e a análise de JSON produz um objeto com uma propriedade `alg`.
Um segmento contendo hífen ou sublinhado segue a mesma sequência com as duas substituições de símbolos primeiro. ToolAcre executa essas operações dentro de `base64ToBytes` e, em seguida, `decodeSegment` analisa o texto resultante. O algoritmo exibido é o que o cabeçalho não verificado declara; ela não está selecionada como política de verificação.
Unicode em declarações — por que os bytes decodificados devem ser lidos como UTF-8 para exibir os nomes corretamente
As reivindicações podem conter acentos, CJK caracteres ou emojis. Base64 opera em bytes, portanto, tratar cada byte decodificado como um caractere independente corrompe o texto multibyte. O caminho correto são símbolos codificados em bytes e, em seguida, um decodificador UTF-8. ToolAcre constrói `TextDecoder` com modo fatal, então UTF-8 inválido falha ruidosamente.
Os testes cobrem uma carga contendo `Zoë 世界 🙂` e esperam a string exata após a decodificação. Esse resultado prova que o pipeline byte-to-text preservou esse valor de teste. Ainda não diz nada sobre se a pessoa nomeada pela carga útil existe, se o emissor aprovou a reivindicação ou se o token foi alterado.
O que isso não cobre – o segmento de assinatura, que é decodificado em bytes em vez de texto e precisa de uma chave para significar alguma coisa
O segmento de assinatura está fora do caminho JSON. ToolAcre mantém sua forma codificada original e tenta apenas medir o comprimento do byte decodificado. Assinatura inválida Base64 produz um aviso, mas não impede a inspeção de cabeçalho e carga útil; um terceiro segmento vazio produz um aviso diferente de que nenhum byte de assinatura está presente.
Nenhum dos resultados é um resultado de verificação. A validação de assinatura significativa precisa de material de chave confiável, um algoritmo permitido escolhido independentemente da entrada controlada pelo invasor e verificações de aplicativos. Uma contagem de bytes é útil ao diagnosticar a forma, mas zero ou trinta e dois bytes medidos não podem autorizar uma solicitação ou estabelecer um emissor.
Conclusão: use um decodificador que fale base64url - o decodificador ToolAcre JWT lida com o alfabeto e o preenchimento do cabeçalho e da carga útil
Use um decodificador que entenda base64url quando a tarefa imediata estiver inspecionando JSON. ToolAcre lida com o alfabeto, preenchimento omitido, UTF-8 estrito e JSON somente objeto para os dois primeiros segmentos. Ele também rejeita comprimentos impossíveis e agrupa falhas de análise em mensagens que identificam se o cabeçalho ou a carga falhou.
Pare nesse limite. Uma decodificação limpa significa que a string tinha bytes recuperáveis e objetos JSON adequados. Isso não significa que suas reivindicações sejam confiáveis, autenticadas, autorizadas ou não modificadas. Somente um verificador configurado separadamente pode responder a essas perguntas, e esta ferramenta de navegador não expõe deliberadamente nenhuma operação de verificação.