Outils de développement · Décodeur JWT
L'en-tête JWT expliqué : alg, typ, kid et les champs dont il faut se méfier
· Comment ça marche
jwt sécurité authentification
L'en-tête indique au vérificateur comment le jeton a été signé et quelle clé utiliser. Cet article explique chaque champ d'en-tête commun, sur quoi un vérificateur peut s'appuyer et quels champs ne doivent jamais être fiables à partir du jeton lui-même.
Le petit objet JSON que personne ne lit — et les décisions de vérification qu'il influence
L'en-tête est suffisamment petit pour être ignoré, mais ses champs participent souvent au routage de vérification. Il est donc dangereux de confondre visibilité et autorité. ToolAcre décode l'en-tête en tant qu'objet JSON et affiche ses propriétés, mais chaque octet provient du détenteur du jeton et reste une entrée non fiable.
Un vérificateur peut utiliser une valeur d'en-tête uniquement dans les contraintes établies à partir d'une configuration approuvée. Il ne doit pas laisser le jeton inventer un algorithme, un émetteur ou une source de clé distante accepté. Le travail du décodeur se termine à JSON lisible plus des avertissements ; il ne choisit jamais de clé ni ne produit de décision d'autorisation ou de refus.
alg display : le décodeur explique uniquement les algorithmes nommés dans son implémentation
`alg` déclare l'algorithme utilisé par le jeton revendiqué. ToolAcre contient des notes explicatives pour HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384 et PS512, ainsi qu'un avertissement pour `none`. Toute autre chaîne est affichée comme non reconnue plutôt que traitée comme prise en charge.
Cette liste est une fonctionnalité d'affichage, pas un catalogue d'algorithmes que ToolAcre peut vérifier : il n'en vérifie aucun. Un backend doit épingler ses choix autorisés de manière indépendante et rejeter une inadéquation. La lecture de `alg: RS256` ne peut pas prouver que RSA a été utilisé, tout comme la lecture de `alg: none` ne peut pas autoriser en toute sécurité un jeton non signé.
typ et cty — déclarant le type de jeton, le profil at+jwt pour les jetons d'accès et les JWT imbriqués
`typ` décrit le type de média ou le profil souhaité par le producteur. ToolAcre avertit lorsqu'une valeur de chaîne diffère de `JWT` ; il n'applique pas la sémantique du profil. Un champ `cty` peut décrire un contenu imbriqué, mais le décodeur actuel n'a pas de chemin de traitement de jeton imbriqué et n'interprète pas ce champ.
Le typage explicite peut aider un vérificateur à séparer les différentes classes de jetons lorsque sa politique définit les valeurs attendues. Le chèque appartient toujours à ce vérificateur. Un jeton ne peut pas devenir un jeton d'accès simplement en annonçant une étiquette préférée, et un panneau de décodage ne peut pas déterminer quel point de terminaison d'application doit le consommer.
kid — l'identifiant de clé qui permet aux vérificateurs de faire pivoter les clés sans temps d'arrêt
`kid` est un identifiant de clé, pas un élément de clé ni une preuve de propriété. Un service qui alterne plusieurs clés de confiance peut utiliser un contexte d'émetteur authentifié et un identifiant contraint pour localiser un candidat. L'identifiant doit rester saisi dans une recherche contrôlée plutôt qu'un chemin de fichier, un fragment de requête ou une URL arbitraire.
ToolAcre laisse `kid` visible dans l'en-tête JSON mais ne le résout pas. Cette retenue est importante : aucun magasin de clés de confiance n'est disponible sur une page de décodage publique. Si un 401 suit la rotation, comparez l'identifiant affiché avec l'inventaire et les journaux de clés côté serveur sans supposer que la clé suggérée par le jeton est légitime.
jku, x5u, jwk et x5c — champs d'en-tête qui pointent vers des clés et pourquoi un vérificateur ne doit jamais les récupérer ou leur faire confiance aveuglément
Des champs tels que `jku` et `x5u` peuvent nommer des emplacements, tandis que `jwk` et `x5c` peuvent contenir des données liées aux clés. Leur présence ne confère pas de confiance à ces lieux ou à ces valeurs. Récupérer une URL ou accepter du matériel intégré uniquement parce qu'un en-tête non vérifié l'a fourni donne une décision de sécurité au demandeur.
Un vérificateur sécurisé obtient des clés via une relation avec l'émetteur et une politique de réseau établie en dehors du jeton. ToolAcre ne récupère pas les URL d'en-tête et ne crée pas de confiance à partir des clés intégrées. Lors de l'examen, l'affichage de l'un de ces champs est une invitation à inspecter la configuration du vérificateur, et non une instruction permettant de suivre l'en-tête.
crit — extensions qu'un vérificateur doit comprendre ou rejeter
`crit` signale que des extensions particulières nécessitent une compréhension de la part du destinataire. Un vérificateur qui prend en charge une telle extension a besoin d’un chemin d’implémentation et de rejet explicite pour les noms critiques inconnus. Ignorer un marqueur critique inconnu peut amener le producteur et le consommateur à interpréter différemment le contenu protégé.
L'implémentation de décodage uniquement ne traite pas `crit`, elle peut donc afficher le tableau brut sans revendiquer la compatibilité. C’est une autre frontière entre l’inspection et la validation. Si un jeton de production repose sur des extensions critiques, vérifiez le comportement dans la bibliothèque et la configuration réelles plutôt que de déduire la prise en charge à partir de JSON lisible.
Exemple concret : lire un en-tête réaliste et décider quels champs informent sur la vérification et lesquels sont simplement informatifs
Considérez `{"alg":"RS256","typ":"JWT","kid":"rotate-7"}`. ToolAcre imprime joliment les trois champs et explique que la vérification RS256 nécessite une clé publique de l'émetteur. Un réviseur peut noter l’algorithme déclaré et l’identifiant de clé, puis les comparer avec la politique épinglée du serveur et l’ensemble de clés de confiance.
Les champs éclairent l'enquête mais ne décident rien de manière indépendante. Si le serveur autorise uniquement un autre algorithme, ne trouve pas `rotate-7` dans le bon ensemble d'émetteurs ou rejette la signature, l'en-tête lisible ne remplace pas ce résultat. De même, la modification du texte d’en-tête sans recalculer une signature valide ne doit pas être acceptée.
À retenir : l'en-tête est une entrée, pas une autorité - le décodeur ToolAcre JWT affiche l'en-tête afin que vous puissiez le lire ; le vérificateur doit décider indépendamment à quoi faire confiance
Traitez l'en-tête JWT comme une entrée et non comme une autorité. Ses valeurs peuvent permettre de sélectionner parmi des choix déjà autorisés par configuration, d'identifier un probable problème de rotation ou d'expliquer une inadéquation de profil. Ils ne peuvent pas établir de confiance dans leur propre algorithme, clé, URL ou type de jeton.
Utilisez ToolAcre pour lire un en-tête de test et faire apparaître des valeurs suspectes telles que `alg` manquant, `none` ou un `typ` inattendu. Passez ensuite au vérificateur configuré pour chaque décision conséquente. Le décodage ne prouve pas l’authenticité, l’intégrité, l’autorisation ou l’identité de l’émetteur, quelle que soit la plausibilité de l’en-tête.