Ferramentas de desenvolvedor · Decodificador JWT
JWE Explicado: Por que um JWT criptografado tem cinco partes e nenhuma carga útil legível
· Fundo
jwt criptografia formatos de dados
Alguns tokens têm quatro pontos em vez de dois e uma carga útil que não é JSON. Esta postagem explica a serialização compacta JWE, o que cada uma de suas cinco partes contém e por que nenhuma ferramenta somente decodificação pode mostrar suas reivindicações.
Quatro pontos e uma carga útil que não é JSON — os sinais de que você está segurando um JWE, não um JWS
Quatro pontos e cinco segmentos indicam um envelope compacto diferente do familiar formulário assinado em três partes. Tentar analisar seus bytes intermediários como afirmações JWT produz absurdo porque o conteúdo é texto cifrado, não uma ortografia base64url de texto simples JSON.
ToolAcre verifica a contagem de segmentos antes da decodificação. Cinco partes acionam uma mensagem INVALID_JWT que identifica um JWE e explica por que não há nada para esta rota somente decodificação mostrar sem uma chave de descriptografia. Esse é um limite preciso, em vez de uma vaga falha de análise.
As cinco partes – cabeçalho protegido, chave criptografada, vetor de inicialização, texto cifrado e etiqueta de autenticação
As partes compactas JWE representam um cabeçalho protegido, material de chave criptografada, um valor de inicialização, texto cifrado e uma etiqueta de autenticação. Cada um tem uma função criptográfica distinta. A posição do segmento por si só não torna o segundo ou quarto campo uma carga útil JWT legível.
Um decodificador pode dividir e decodificar base64url alguns bytes, mas bytes brutos não são descriptografia. Exibi-los como texto criaria caracteres de substituição ou fragmentos enganosos. A ação correta é identificar o envelope e passar para uma implementação de destinatário autorizado.
alg e enc — gerenciamento de chaves versus criptografia de conteúdo e por que um cabeçalho JWE nomeia dois algoritmos
Um cabeçalho JWE pode conter `alg` para gerenciamento de chaves e `enc` para criptografia de conteúdo. Esses rótulos descrevem diferentes operações. Tal como acontece com os tokens assinados, os valores do cabeçalho são entradas que devem corresponder à política do destinatário, em vez da permissão para o token selecionar algoritmos arbitrários.
As notas do algoritmo de três partes de ToolAcre não implementam o processamento de JWE e a ramificação de cinco partes sai antes da análise do cabeçalho. A página, portanto, não exibe nem endossa algoritmos de criptografia específicos. Consulte a biblioteca do destinatário e o contrato do emissor para conhecer as opções suportadas.
Chaves de criptografia de conteúdo — como uma chave aleatória protege a carga útil e é empacotada para o destinatário
A criptografia de conteúdo geralmente usa uma chave de criptografia de conteúdo gerada, enquanto o segmento de chave criptografada transmite ou deriva essa chave sob o arranjo do destinatário. A separação permite que os bytes de carga útil sejam protegidos com uma cifra de conteúdo enquanto a política de gerenciamento de chaves determina quem pode recuperar a chave.
Este modelo conceitual explica por que possuir a string compacta é insuficiente para recuperação de texto simples. Os segredos e políticas do destinatário necessários não são codificados como instruções de uso livre. Um decodificador público não pode inventá-los e nunca deve pedir aos usuários que colem chaves de descriptografia privadas em uma página genérica.
Quando os emissores escolhem JWE — reivindicações que devem permanecer confidenciais do cliente ou de intermediários
Os emissores podem selecionar a criptografia quando as reivindicações devem permanecer confidenciais dos detentores ou intermediários que podem ver um token assinado. Se essa é a escolha certa depende do modelo de ameaça, da distribuição de chaves e dos requisitos operacionais. Minimizar o conteúdo da declaração ainda pode ser preferível à criptografia de dados desnecessários.
A criptografia não elimina questões de autorização, validação ou metadados. O destinatário deve autenticar o conteúdo protegido e aplicar a política de token após a descriptografia. Um resultado legível obtido por um destinatário autorizado não é automaticamente aceitável para todos os serviços.
Por que a decodificação para no cabeçalho — a carga útil é um texto cifrado, então apenas o detentor da chave pode lê-lo
A decodificação para na estrutura porque o possível segmento de carga útil é o texto cifrado. ToolAcre evita deliberadamente apresentar binário arbitrário como JSON e, em vez disso, fornece uma mensagem específica. Isso evita que os usuários interpretem jargões como corrupção em um envelope criptografado válido.
Se você for o destinatário pretendido, use software controlado configurado com a chave e os algoritmos apropriados. Caso contrário, a carga ilegível será a propriedade de segurança esperada. Nenhum truque de preenchimento ou decodificador de caracteres alternativo pode substituir a descriptografia.
O que isso não cobre: JWTs aninhados que são assinados e criptografados e serialização JWE JSON
Construções aninhadas podem assinar conteúdo e criptografar o resultado ou combinar camadas sob um perfil definido. JWE também possui representações além da string compacta de cinco partes. ToolAcre não processa esses casos e este artigo não infere o aninhamento apenas a partir de um rótulo de cabeçalho.
Documente qual camada seu sistema espera antes de solucionar problemas. Caso contrário, uma equipe pode tentar verificar a assinatura no texto cifrado ou decodificar um token interno que não tenha sido autenticado. Deixe a biblioteca JOSE selecionada lidar com pedidos sob política explícita.
Conclusão: um decodificador só pode mostrar o que não está criptografado - o decodificador ToolAcre JWT mostra o cabeçalho e a carga útil de um token assinado; a carga útil de um JWE é ilegível por design
Um decodificador pode mostrar apenas o que não está criptografado. ToolAcre lê JSON do cabeçalho e da carga útil da entrada assinada em três partes, enquanto cinco segmentos causam uma parada explicativa. Essa distinção impede que uma interface somente decodificada finja que possui capacidade de destinatário.
Use a contagem de segmentos como uma pista de roteamento, não como um resultado de confiança. Três partes legíveis ainda requerem verificação de assinatura; cinco partes criptografadas requerem descriptografia e validação autorizadas. Em nenhum dos casos a saída visual por si só autentica reivindicações ou concede acesso.