Outils de développement · Décodeur JWT
Anatomie d'un JWT : fractionnement en points et décodage de Base64url
· Comment ça marche
jwt encodage sécurité
Un JWT est constitué de trois segments base64url séparés par des points. Cet article décode chaque partie à la main, explique pourquoi le segment de signature n'est pas du texte et montre ce qu'un décodeur peut et ne peut pas vous dire.
La longue chaîne dans l'en-tête Autorisation : ce que vous regardez et pourquoi elle comporte exactement deux points
Un jeton de porteur arrive souvent dans un en-tête Authorization sous la forme d'une chaîne compacte séparée par des points. Un JWT signé typique sous forme JWS compacte comporte trois segments et donc deux points de séparation. Un token actif est un identifiant : ne collez pas de tokens de production dans une démonstration.
Sérialisation compacte : en-tête, charge utile et signature sous forme de trois segments base64url
Dans la sérialisation JWS compacte, le premier segment est l'en-tête protégé, le deuxième est la charge utile et le troisième est une signature ou MAC. La signature couvre les deux premiers segments codés, reliés par un point. Le fractionnement de la chaîne localise les segments ; il ne peut pas établir la confiance.
Base64url sans remplissage - l'alphabet utilisé par JWS et pourquoi les segments n'ont pas de signe égal à la fin
Base64url utilise - et _ à la place de + et / dans Base64 ordinaire. Compact JWS omet le trail = padding ; un décodeur peut restaurer le remplissage avant le décodage. Le décodage produit des octets. Pour l'en-tête et les revendications JSON, décodez les octets au format UTF-8 avant d'analyser le texte.
L'en-tête — un petit objet JSON nommant l'algorithme et, souvent, la clé
L'en-tête est généralement du JSON contenant alg et parfois un identifiant de clé, kid. Ce sont des affirmations faites par le jeton lui-même. Un vérificateur doit appliquer sa propre politique d'algorithme autorisé et obtenir en toute sécurité la clé appropriée ; lire alg seul n’est pas une autorisation.
La charge utile - un objet de réclamation JSON, lisible par toute personne détenant le jeton
La charge utile contient des revendications telles que sub, exp et aud. Toute personne détenant le jeton peut les lire ; l'encodage n'est pas un cryptage. Une exp NumericDate compte les secondes depuis l'époque Unix, mais une réclamation non vérifiée n'a aucune autorité. Ne stockez pas de secrets dans une charge utile lisible.
La signature - octets bruts sur les deux premiers segments, dénués de sens en tant que texte et inutiles sans clé
Le dernier segment est constitué d'octets de signature codés en base64url, et non d'un troisième objet JSON. Sa validation nécessite un algorithme cryptographique, une clé et une politique d'application. ToolAcre n'effectue délibérément pas de vérification : il signale la présence de la signature et marque toujours signatureVerified false.
Exemple pratique : décoder un exemple de jeton segment par segment, y compris le JSON qui apparaît
Prenez l'en-tête de démonstration non sensible {"alg": "HS256", "typ": "JWT"} et la charge utile {"sub": "demo"}. Leurs codages base64url sont eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 et eyJzdWIiOiJkZW1vIn0. Le décodage récupère le JSON. L'ajout d'un troisième segment arbitraire ne rend pas le jeton authentique.
À retenir : le décodage consiste à lire, pas à faire confiance – le décodeur ToolAcre JWT affiche l'en-tête et la charge utile et ne vérifie jamais la signature, donc rien de ce qu'il montre ne prouve que le jeton est authentique
Le décodage, c'est la lecture, pas la confiance. Utilisez le décodeur ToolAcre JWT pour l'en-tête, les réclamations et les avertissements d'un jeton jetable ; utilisez le vérificateur de confiance de votre application pour décider si un jeton signé est valide. Les revendications affichées ne doivent jamais accorder l'accès à elles seules.