Outils de développement · Décodeur JWT
Vérifications de l'audience et des émetteurs : empêcher la relecture d'un JWT ailleurs
· Pourquoi c'est important
jwt authentification sécurité
Un jeton émis pour un service peut être présenté à un autre qui partage le même émetteur. Cet article explique comment les vérifications aud et iss arrêtent cela et comment lire les deux réclamations dans un jeton.
Le service B accepte un jeton destiné au service A — la rediffusion interservices qu'une signature valide n'empêche pas
Une signature peut être valide pour un jeton qui a été émis vers un autre service. Si plusieurs API font confiance à la même plateforme d'identité mais ignorent le contexte du destinataire, un identifiant destiné au service A peut être rejoué au service B. L'intégrité cryptographique à elle seule ne permet pas de déterminer qui doit le consommer.
ToolAcre peut révéler `iss` et `aud` afin qu'un développeur puisse repérer une inadéquation évidente. Ces chaînes restent non vérifiées jusqu'à ce que la signature réussisse, et l'outil de navigation n'effectue jamais cette vérification. Le serveur de ressources réel doit faire respecter à la fois sa relation d'émetteur et son public cible.
iss — lier un jeton à l'émetteur auquel votre service fait confiance, et pourquoi une correspondance de chaîne n'est pas suffisante sans liaison de clé
`iss` identifie l'entité pour laquelle la charge utile prétend avoir émis le jeton. Un vérificateur a besoin d'un émetteur attendu exact dans sa propre configuration et doit lier cette identité à la relation clé-découverte correcte. La comparaison de texte sans la liaison cryptographique laisse la possibilité à un attaquant de copier la chaîne attendue.
Le décodeur décrit `iss` comme « qui a créé le jeton », mais il s'agit de la signification enregistrée et non d'une découverte sur une valeur collée. Le texte lisible de l’émetteur constitue une preuve utile pour le débogage de la configuration. Il ne peut pas sélectionner une source de clé arbitraire ni s'authentifier.
aud — une chaîne ou un tableau nommant les destinataires prévus et la règle selon laquelle un vérificateur doit s'y trouver
`aud` nomme les destinataires prévus et peut apparaître sous la forme d'une chaîne ou d'une collection. La politique du serveur de ressources doit se retrouver dans la valeur authentifiée en utilisant les règles de comparaison exactes requises par son profil. Il ne doit pas accepter un jeton simplement parce qu'un autre service familier est répertorié.
ToolAcre contient les tableaux sous forme de texte JSON dans son tableau de revendications, préservant leur structure visible pour l'inspection. Il ne connaît pas l’identifiant actuel de l’API et ne peut pas décider d’une correspondance. Cette absence volontaire empêche un décodeur générique d'inventer un contexte d'autorisation qu'il ne possède pas.
azp et scope — les revendications OpenID Connect et OAuth qui précisent qui peut utiliser le jeton et pour quoi
`azp` et `scope` peuvent ajouter du contexte sur une partie autorisée et les autorisations demandées dans les profils qui les définissent. Ils ne remplacent pas les contrôles d’audience, d’émetteur ou de signature. Un nom de portée est une assertion et non une autorisation accordée jusqu'à ce que le serveur de ressources mappe une valeur authentifiée à sa propre stratégie.
Le décodeur actuel les traite comme des revendications spécifiques à l'application car sa table de description enregistrée couvre sept noms principaux. Il affiche leurs valeurs mais ne fournit aucune sémantique OpenID Connect ou OAuth. Consultez le profil applicable et le contrat de prestataire avant de les utiliser dans une décision.
Le modèle des députés confus : comment un jeton légitime devient une attaque lorsque les audiences ne sont pas vérifiées
Un adjoint confus utilise son autorité légitime dans un contexte involontaire. Un jeton accepté par le mauvais service peut déclencher exactement ce modèle même si personne n'a falsifié la signature. Les contrôles d'audience limitent les endroits où les allégations authentifiées peuvent être appliquées, tandis que les contrôles de l'émetteur limitent les assertions prises en compte par le service.
C'est pourquoi un indicateur général de « signature valide » serait encore insuffisant. L'autorisation dépend du destinataire et de l'exploitation. ToolAcre évite entièrement cette ambiguïté en ne signalant aucun résultat de vérification, laissant le service consommateur combiner la cryptographie avec la politique contextuelle.
Exemple pratique : lire iss et aud à partir de deux jetons dans le décodeur ToolAcre JWT et décider quel service doit accepter chacun
Créez deux jetons inoffensifs dont les charges utiles décodées ne diffèrent que par `aud` : l'un nomme `service-a`, l'autre `service-b` ; les deux revendiquent le même émetteur. ToolAcre rend la différence visible. Un vérificateur du service A ne devrait accepter ni l'un ni l'autre de cet affichage et devrait rejeter l'audience authentifiée du service B.
Puis inversez l'exercice avec deux chaînes d'émetteur. Le texte attendu à lui seul ne suffit pas, sauf si la vérification utilise des clés fiables pour cet émetteur. Ces exemples séparent l'inspection de l'acceptation et montrent pourquoi la copie des affirmations correctes dans un jeton fabriqué ne modifie aucune politique fiable.
Ce que cela ne couvre pas : la vérification de la signature, que le décodeur n'effectue jamais ; les contrôles aud et iss n'ont d'importance qu'une fois la signature conservée
Les contrôles d'audience et d'émetteur n'ont d'importance qu'une fois que la vérification cryptographique a établi que les octets protégés correspondent à des éléments de clé fiables. ToolAcre n'effectue aucune de ces vérifications. Ses résultats ne peuvent pas établir qu'une réclamation a survécu intacte ou qu'elle a été rédigée par un émetteur connu.
Il ne récupère pas non plus les métadonnées, ne choisit pas les clés et ne compare pas les destinataires configurés. Utilisez des tests back-end et des journaux pour prouver le rejet d’un mauvais émetteur et d’un mauvais public. Une correspondance visuelle dans un décodeur est un indice de débogage, jamais une preuve d'autorisation suffisante.
À retenir : vérifiez à qui il s'adresse, pas seulement qui l'a signé - le décodeur ToolAcre JWT affiche les revendications aud et iss que vous devez comparer
Vérifiez à qui est destiné le jeton, pas seulement le nom indiqué qui l'a signé. Le flux robuste authentifie les octets protégés dans le cadre d'une relation d'émetteur de confiance indépendante, puis nécessite une audience acceptable et applique des règles d'autorisation spécifiques au service.
Utilisez ToolAcre pour lire les valeurs de test sûres et formuler la prochaine vérification côté serveur. Ne choisissez pas de clés de vérification à partir de données d'en-tête ou de réclamation non fiables, et ne transformez pas `iss`, `aud`, `azp` ou `scope` affichés en une subvention sans le flux de confiance complet.