Outils de développement · Décodeur JWT
JWE expliqué : pourquoi un JWT crypté comporte cinq parties et aucune charge utile lisible
· Contexte
jwt cryptage formats de données
Certains jetons ont quatre points au lieu de deux et une charge utile qui n'est pas JSON. Cet article explique la sérialisation compacte JWE, ce que contient chacune de ses cinq parties et pourquoi aucun outil uniquement de décodage ne peut montrer ses prétentions.
Quatre points et une charge utile qui n'est pas JSON — les signes que vous détenez un JWE, pas un JWS
Quatre points et cinq segments indiquent une enveloppe compacte différente du formulaire signé en trois parties familier. Essayer d'analyser ses octets du milieu comme le prétend JWT produit un non-sens car le contenu est un texte chiffré, et non une orthographe base64url du texte en clair JSON.
ToolAcre vérifie le nombre de segments avant le décodage. Cinq parties déclenchent un message INVALID_JWT qui identifie un JWE et explique pourquoi il n'y a rien à afficher pour cette route de décodage uniquement sans clé de déchiffrement. Il s’agit d’une limite précise plutôt que d’un vague échec d’analyse.
Les cinq parties : en-tête protégé, clé chiffrée, vecteur d'initialisation, texte chiffré et balise d'authentification
Les parties JWE compactes représentent un en-tête protégé, un matériel de clé chiffrée, une valeur d'initialisation, un texte chiffré et une balise d'authentification. Chacun a un rôle cryptographique distinct. La position du segment à elle seule ne fait pas du deuxième ou du quatrième champ une charge utile JWT lisible.
Un décodeur peut diviser et décoder en base64url certains octets, mais les octets bruts ne sont pas un décryptage. Les afficher sous forme de texte créerait des caractères de remplacement ou des fragments trompeurs. L'action correcte consiste à identifier l'enveloppe et à passer à une implémentation de destinataire autorisé.
alg et enc — gestion des clés par rapport au cryptage du contenu, et pourquoi un en-tête JWE nomme deux algorithmes
Un en-tête JWE peut contenir `alg` pour la gestion des clés et `enc` pour le cryptage du contenu. Ces étiquettes décrivent différentes opérations. Comme pour les jetons signés, les valeurs d'en-tête sont des entrées qui doivent correspondre à la politique du destinataire plutôt qu'à l'autorisation du jeton de sélectionner des algorithmes arbitraires.
Les notes d'algorithme en trois parties de ToolAcre n'implémentent pas le traitement JWE et la branche en cinq parties se termine avant l'analyse de l'en-tête. La page n’affiche donc ni n’approuve d’algorithmes de cryptage particuliers. Consultez la bibliothèque destinataire et le contrat de l'émetteur pour connaître les choix pris en charge.
Clés de chiffrement de contenu : comment une clé aléatoire protège la charge utile et est elle-même encapsulée pour le destinataire
Le chiffrement de contenu utilise généralement une clé de chiffrement de contenu générée, tandis que le segment de clé chiffrée transmet ou dérive cette clé selon l'accord du destinataire. La séparation permet aux octets de charge utile d'être protégés par un chiffrement de contenu tandis que la politique de gestion des clés détermine qui peut récupérer la clé.
Ce modèle conceptuel explique pourquoi la possession de la chaîne compacte est insuffisante pour la récupération du texte en clair. Les secrets et la politique du destinataire requis ne sont pas codés sous forme d'instructions librement utilisables. Un décodeur public ne peut pas les inventer et ne devrait jamais demander aux utilisateurs de coller des clés privées de déchiffrement dans une page générique.
Lorsque les émetteurs choisissent JWE — les réclamations doivent rester confidentielles du client ou des intermédiaires
Les émetteurs peuvent sélectionner le cryptage lorsque les réclamations doivent rester confidentielles auprès des détenteurs ou des intermédiaires qui peuvent voir un jeton signé. Que ce soit le bon choix dépend du modèle de menace, de la distribution des clés et des exigences opérationnelles. Minimiser le contenu des réclamations peut toujours être préférable au chiffrement des données inutiles.
Le chiffrement n’élimine pas les problèmes d’autorisation, de validation ou de métadonnées. Le destinataire doit authentifier le contenu protégé et appliquer la politique de jeton après le décryptage. Un résultat lisible obtenu par un destinataire autorisé n'est pas automatiquement acceptable pour chaque service.
Pourquoi le décodage s'arrête au niveau de l'en-tête : la charge utile est un texte chiffré, donc seul le détenteur de la clé peut le lire
Le décodage s'arrête à la structure car le segment de charge utile potentiel est un texte chiffré. ToolAcre évite délibérément de présenter un binaire arbitraire comme JSON et donne à la place un message spécifique. Cela empêche les utilisateurs d'interpréter le charabia comme une corruption dans une enveloppe cryptée par ailleurs valide.
Si vous êtes le destinataire prévu, utilisez un logiciel contrôlé configuré avec la clé et les algorithmes appropriés. Si ce n’est pas le cas, la charge utile illisible est la propriété de sécurité attendue. Aucune astuce de remplissage ou décodeur de caractères alternatif ne peut remplacer le décryptage.
Ce que cela ne couvre pas : les JWT imbriqués qui sont signés puis chiffrés, et la sérialisation JWE JSON
Les constructions imbriquées peuvent signer le contenu puis chiffrer le résultat, ou autrement combiner des couches sous un profil défini. JWE a également des représentations au-delà de la chaîne compacte en cinq parties. ToolAcre ne traite pas ces cas et cet article ne déduit pas l'imbrication simplement à partir d'une étiquette d'en-tête.
Documentez la couche attendue par votre système avant le dépannage. Sinon, une équipe peut tenter de vérifier la signature sur un texte chiffré ou décoder un jeton interne qui n'a pas été authentifié. Laissez la bibliothèque JOSE sélectionnée gérer la commande selon une politique explicite.
À retenir : un décodeur ne peut afficher que ce qui n'est pas crypté – le décodeur ToolAcre JWT affiche l'en-tête et la charge utile d'un jeton signé ; la charge utile d'un JWE est illisible de par sa conception
Un décodeur peut afficher uniquement ce qui n'est pas crypté. ToolAcre lit JSON à partir de l'en-tête et de la charge utile de l'entrée signée en trois parties, tandis que cinq segments provoquent un arrêt explicatif. Cette distinction empêche une interface de décodage uniquement de prétendre avoir une capacité de réception.
Utilisez le nombre de segments comme indice de routage, et non comme résultat de confiance. Trois parties lisibles nécessitent encore une vérification de signature ; cinq parties cryptées nécessitent un décryptage et une validation autorisés. Dans aucun des deux cas, la sortie visuelle n’authentifie à elle seule les revendications ou n’accorde l’accès.