Ferramentas de desenvolvedor · Decodificador JWT
Decodificar versus verificar: o que uma assinatura JWT prova e por que os decodificadores a ignoram
· Como funciona
jwt segurança criptografia
A decodificação não precisa de chave; a verificação precisa do caminho certo. Esta postagem explica o que a assinatura cobre, como HMAC e verificação assimétrica diferem e por que uma ferramenta somente decodificação é honesta em não provar nada.
Ele foi decodificado corretamente, portanto deve ser válido – a suposição que leva à aceitação de tokens falsificados
Um token pode ser decodificado perfeitamente depois que um invasor escreve uma nova carga útil e anexa um texto arbitrário como o terceiro segmento. A análise Base64url e JSON são transformações públicas; nenhum dos dois verifica quem montou a string. “As reivindicações apareceram na tela” não é, portanto, prova de que o emissor as criou ou aprovou.
ToolAcre reforça esse limite em vários lugares. O resultado sempre carrega `signatureVerified: false`, a IU repete um alerta de declarações não verificadas ao lado da saída e os testes afirmam que não há superfície `valid` ou `verify`. Isso é honestidade deliberada, não um recurso de conveniência que falta.
O que a assinatura cobre – os bytes exatos do cabeçalho codificado e da carga útil, unidos por um ponto
Para JWS compacto, a entrada de assinatura é o segmento de cabeçalho protegido codificado, um ponto literal e o segmento de carga útil codificado. A verificação diz respeito aos bytes codificados exatos, e não ao JSON recém-impresso. Reordenar propriedades ou alterar espaços em branco pode criar bytes diferentes, mesmo quando um ser humano vê objetos equivalentes.
O terceiro segmento carrega assinatura codificada ou MAC bytes produzidos nessa entrada. ToolAcre preserva o segmento bruto e pode relatar seu comprimento em bytes, mas nunca executa uma verificação criptográfica. Medir a forma dos dados não pode estabelecer que a chave esperada os criou ou que os dois primeiros segmentos permaneceram inalterados.
HMAC versus assimétrico — um segredo compartilhado que qualquer pessoa que possa verificar também pode forjar, versus uma chave pública que só pode verificar
Com HMAC, um segredo compartilhado suporta a criação e a verificação de MAC. Uma parte capaz de verificar esse segredo também pode cunhar outro token, portanto a distribuição secreta define o limite de confiança. As notas de ToolAcre tornam esta consequência explícita para seus rótulos de algoritmo HS reconhecidos.
Assinaturas assimétricas separam a capacidade de assinatura privada do material de verificação pública. Possuir uma chave pública pode apoiar a verificação sem conceder autoridade de assinatura. Essa distinção não torna confiável um rótulo assimétrico declarado no cabeçalho: o verificador já deve saber qual algoritmo e chave do emissor são aceitáveis.
De onde vem a chave — configuração para segredos compartilhados, um endpoint JWKS para chaves públicas, correspondido por criança
Os segredos compartilhados devem vir da configuração do serviço protegido, e não do texto do token. As chaves de verificação públicas podem vir de um relacionamento de emissor confiável e de um conjunto de chaves controladas. Um `kid` pode ajudar a selecionar dentro desse conjunto, mas não deve transformar conteúdo arbitrário de cabeçalho não confiável em um arquivo, banco de dados ou pesquisa de rede.
ToolAcre não tem configuração de emissor e não solicita chave, portanto seria impossível realizar a verificação de forma responsável. Uma página web genérica não pode inferir em qual organização você confia, qual público você atende ou quais algoritmos seu aplicativo permite. Essas são entradas de políticas de aplicativos, não propriedades detectáveis por decodificação.
Por que a decodificação não precisa de chave – base64url é uma codificação, não uma criptografia, então qualquer pessoa pode ler as declarações
Nenhuma chave é necessária para decodificar porque base64url é uma codificação reversível em vez de criptografia. O cabeçalho e a carga útil devem viajar com o token e podem ser recuperados por qualquer detentor. Isto permite uma inspeção útil, mas também significa que as informações confidenciais não devem ser escondidas atrás do ruído visual dos caracteres codificados.
A análise JSON adiciona apenas estrutura. Ele pode dizer que `roles` é uma matriz ou `exp` é um número, e não que nenhum dos valores seja autêntico. ToolAcre renderiza valores estruturados como texto e descrições registradas como documentação, deixando autorização para o sistema que pode verificar e aplicar a política.
Exemplo resolvido - um token com um caractere de carga útil alterado ainda é decodificado perfeitamente; apenas avisos de verificação
Comece com um token sintético cuja carga diz `{"sub":"demo","role":"reader"}`. Altere um caractere de carga útil codificado para que os bytes ainda formem JSON válido, talvez produzindo uma função diferente. Ambas as versões podem dividir, decodificar e imprimir lindamente. O caminho de decodificação não tem motivo para rejeitar a versão alterada.
Um verificador configurado corretamente recalcula ou verifica o resultado criptográfico na entrada de assinatura alterada e rejeita a incompatibilidade. Esta comparação demonstra o limite preciso: o sucesso do decodificador cobre a sintaxe, enquanto o sucesso do verificador pode estabelecer a integridade relativa a uma chave confiável e a um algoritmo permitido antes que a política de declaração seja avaliada.
O que isso não cobre – o decodificador ToolAcre JWT nunca verifica a assinatura, por design; nada que mostra prova que um token é genuíno
ToolAcre nunca verifica a assinatura. Um segmento vazio recebe um aviso, a codificação de assinatura malformada recebe outro e os bytes mensuráveis são relatados como presentes, mas não verificados. Nenhum desses ramos produz um veredicto de token genuíno. A implementação não possui aquisição de chave oculta ou caminho de execução de algoritmo.
Mesmo a verificação criptográfica bem-sucedida não autorizaria automaticamente uma ação. O serviço consumidor ainda precisa de verificações específicas do emissor, do público, do tempo e da aplicação. Este artigo termina antes da configuração da biblioteca porque o suporte e os padrões variam; consulte o verificador exato e a versão usada pelo seu serviço.
Conclusão: decodifique para inspecionar, verifique para confiar - use o decodificador ToolAcre JWT para o primeiro e uma biblioteca do lado do servidor com a chave certa para o segundo
Decodifique para inspecionar e verificar antes de confiar. Use a ferramenta do navegador para um token expirado ou sintético quando precisar ver campos de cabeçalho, valores de carga útil, conversões de tempo e avisos estruturais. Nunca deixe que a saída legível flua diretamente para uma decisão de acesso.
Transfira o trabalho consequente para um verificador confiável com material chave fornecido de forma independente, algoritmos fixados e política de serviço. Somente esse caminho pode testar a autenticidade e a integridade, e somente as verificações de declarações subsequentes podem decidir a autorização. A recusa de um decodificador em confundir essas tarefas é um recurso de segurança.