Outils de développement · Décodeur JWT
Décoder ou vérifier : ce que prouve une signature JWT et pourquoi les décodeurs l'ignorent
· Comment ça marche
jwt sécurité cryptographie
Le décodage ne nécessite aucune clé ; la vérification a besoin du bon. Cet article explique ce que couvre la signature, en quoi HMAC et la vérification asymétrique diffèrent et pourquoi un outil uniquement de décodage est honnête lorsqu'il ne prouve rien.
Il a bien décodé, il doit donc être valide – l'hypothèse qui conduit à accepter les jetons falsifiés
Un jeton peut parfaitement décoder après qu'un attaquant ait écrit une nouvelle charge utile et joint un texte arbitraire comme troisième segment. L'analyse Base64url et JSON sont des transformations publiques ; ni l’un ni l’autre ne vérifie qui a assemblé la chaîne. « Les réclamations sont apparues à l'écran » ne constitue donc pas une preuve que l'émetteur les a créées ou approuvées.
ToolAcre renforce cette frontière à plusieurs endroits. Le résultat porte toujours `signatureVerified: false`, l'interface utilisateur répète une alerte de réclamation non vérifiée à côté de la sortie et les tests affirment qu'il n'y a pas de surface `valid` ou `verify`. Il s’agit d’une honnêteté délibérée et non d’une fonctionnalité manquante.
Ce que couvre la signature : les octets exacts de l'en-tête et de la charge utile codés, reliés par un point
Pour JWS compact, l'entrée de signature est le segment d'en-tête protégé codé, un point littéral et le segment de charge utile codé. La vérification concerne ces octets codés exacts, et non les JSON fraîchement imprimés. La réorganisation des propriétés ou la modification des espaces peuvent créer différents octets même lorsqu'un humain voit des objets équivalents.
Le troisième segment contient la signature codée ou les octets MAC produits sur cette entrée. ToolAcre préserve le segment brut et peut indiquer sa longueur en octets, mais il n'exécute jamais de vérification cryptographique. La mesure de la forme des données ne permet pas d'établir que la clé attendue l'a créée ou que les deux premiers segments sont restés inchangés.
HMAC contre asymétrique : un secret partagé que toute personne pouvant vérifier peut également falsifier, par opposition à une clé publique qui ne peut que vérifier
Avec HMAC, un secret partagé prend en charge à la fois la création et la vérification du MAC. Une partie capable de vérifier avec ce secret peut également créer un autre jeton, de sorte que la distribution du secret définit la limite de confiance. Les notes de ToolAcre rendent cette conséquence explicite pour ses étiquettes d'algorithme HS reconnues.
Les signatures asymétriques séparent une capacité de signature privée du matériel de vérification public. Posséder une clé publique peut prendre en charge la vérification sans accorder de pouvoir de signature. Cette distinction ne rend pas fiable une étiquette asymétrique déclarée dans l'en-tête : le vérificateur doit déjà savoir quel algorithme et quelle clé d'émetteur sont acceptables.
D'où vient la clé : configuration pour les secrets partagés, un point de terminaison JWKS pour les clés publiques, correspondant à l'enfant
Les secrets partagés doivent provenir de la configuration du service protégé et non du texte du jeton. Les clés de vérification publiques peuvent provenir d’une relation avec un émetteur de confiance et d’un ensemble de clés contrôlées. Un `kid` peut aider à sélectionner dans cet ensemble, mais il ne doit pas transformer le contenu d'en-tête arbitraire et non fiable en une recherche de fichier, de base de données ou de réseau.
ToolAcre n'a pas de configuration d'émetteur et ne demande aucune clé, il serait donc impossible d'y effectuer une vérification de manière responsable. Une page Web générique ne peut pas déduire à quelle organisation vous faites confiance, quel public vous servez ou quels algorithmes votre application autorise. Il s'agit d'entrées de politique d'application, et non de propriétés détectables par décodage.
Pourquoi le décodage ne nécessite aucune clé : base64url est un codage, pas un cryptage, afin que tout le monde puisse lire les affirmations.
Aucune clé n'est nécessaire pour décoder car base64url est un codage réversible plutôt qu'un cryptage. L'en-tête et la charge utile sont destinés à voyager avec le jeton et peuvent être récupérés par n'importe quel détenteur. Cela permet une inspection utile, mais signifie également que les informations confidentielles ne doivent pas être cachées derrière le bruit visuel des caractères codés. L'analyse
JSON ajoute uniquement de la structure. Il peut vous dire que `roles` est un tableau ou `exp` est un nombre, mais qu'aucune des deux valeurs n'est authentique. ToolAcre restitue les valeurs structurées sous forme de texte et les descriptions enregistrées sous forme de documentation tout en laissant l'autorisation au système qui peut vérifier et appliquer la politique.
Exemple concret : un jeton avec un caractère de charge utile modifié décode toujours parfaitement ; uniquement les avis de vérification
Commencez avec un jeton synthétique dont la charge utile indique `{"sub":"demo","role":"reader"}`. Modifiez un caractère de charge utile codé afin que les octets forment toujours un JSON valide, produisant peut-être un rôle différent. Les deux versions peuvent diviser, décoder et joliment imprimer. Le chemin de décodage n'a aucune raison de rejeter la version modifiée.
Un vérificateur correctement configuré recalcule ou vérifie le résultat cryptographique sur l'entrée de signature modifiée et rejette la non-concordance. Cette comparaison démontre la limite précise : le succès du décodeur couvre la syntaxe, tandis que le succès du vérificateur peut établir l'intégrité par rapport à une clé de confiance et à un algorithme autorisé avant que la politique de réclamation ne soit évaluée.
Ce que cela ne couvre pas : le décodeur ToolAcre JWT ne vérifie jamais la signature, de par sa conception ; rien de ce qu'il montre ne prouve qu'un jeton est authentique
ToolAcre ne vérifie jamais la signature. Un segment vide reçoit un avertissement, un codage de signature mal formé en reçoit un autre et les octets mesurables sont signalés comme présents mais non vérifiés. Aucune de ces branches ne produit un véritable verdict symbolique. L'implémentation n'a pas de chemin d'acquisition de clé caché ni de chemin d'exécution d'algorithme.
Même une vérification cryptographique réussie n'autoriserait pas automatiquement une action. Le service consommateur nécessite toujours des contrôles spécifiques à l'émetteur, à l'audience, au temps et à l'application. Cet article s'arrête avant la configuration de la bibliothèque car la prise en charge et les valeurs par défaut varient ; consultez le vérificateur exact et la version utilisée par votre service.
À retenir : décoder pour inspecter, vérifier pour faire confiance - utilisez le décodeur ToolAcre JWT pour le premier et une bibliothèque côté serveur avec la bonne clé pour le second
Décoder pour inspecter et vérifier avant de faire confiance. Utilisez l'outil de navigation pour un jeton expiré ou synthétique lorsque vous avez besoin de voir les champs d'en-tête, les valeurs de charge utile, les conversions de temps et les avertissements structurels. Ne laissez jamais cette sortie lisible se transformer directement en une décision d’accès.
Transférez les travaux conséquents vers un vérificateur de confiance avec des éléments clés fournis indépendamment, des algorithmes épinglés et une politique de service. Seul ce chemin peut tester l'authenticité et l'intégrité, et seules les vérifications de réclamation ultérieures peuvent décider de l'autorisation. Le refus d’un décodeur de brouiller ces tâches est un élément de sécurité.