Résumé

  • RFC 9701 permet à un serveur de ressources authentifié de recevoir une réponse d’introspection JWT signée, éventuellement chiffrée, avec iss, aud, iat et un objet token_introspection séparé.
  • La chaîne probante doit encore relier l’identité de l’appelant, le type du JWT, la signature, le destinataire, la fraîcheur, l’état et les portées du jeton, la base de divulgation, la règle locale, l’antirejeu et l’effet réellement appliqué.

Le serveur d’autorisation répond active:true. La signature est valide. Le champ aud extérieur nomme correctement le serveur de ressources. Il serait tentant de transformer ce faisceau de signaux en un verdict unique : accès accordé. C’est précisément le raccourci que la structure de RFC 9701 permet d’éviter.

L’introspection OAuth 2.0 de RFC 7662 donne au serveur protégé un moyen d’interroger l’état d’un jeton opaque. RFC 9701 ajoute une réponse protégée par JWT lorsque l’attribution de l’information à son émetteur doit être plus forte qu’un objet JSON reçu dans une connexion. La signature rend la déclaration transportable et vérifiable. Le chiffrement facultatif peut en réserver la lecture. Ni l’un ni l’autre ne remplace la politique du serveur qui va agir.

La première autorisation porte sur celui qui pose la question

Avant d’examiner le jeton présenté par l’utilisateur, le serveur d’autorisation doit savoir quel serveur de ressources demande les données. RFC 9701 exige qu’il identifie, authentifie et autorise cet appelant. Une authentification client ou un jeton distinct identifiant le serveur de ressources peut servir ; une requête anonyme doit être refusée.

Cette exigence limite deux pouvoirs. Le serveur d’autorisation ne doit pas divulguer les propriétés d’un jeton à n’importe quel voisin technique. Le serveur de ressources ne doit pas pouvoir réutiliser ses identifiants pour des appels sans rapport avec son rôle. Le texte permet de gérer un serveur de ressources comme un client enregistré, par exemple avec RFC 7591, mais la méthode de provisionnement reste locale.

L’audience du jeton sous-jacent est ensuite comparée à l’identité de l’appelant. Si le jeton est invalide, expiré, révoqué ou destiné à une autre ressource, la réponse imbriquée porte active:false et rien d’autre. Cette forme négative évite qu’un refus livre tout de même un sujet, des portées ou une date d’expiration.

Lorsque le résultat est positif, la portée devrait être réduite à ce qui concerne ce serveur. Les données d’identité suivent une politique propre au destinataire et une base juridique. Deux serveurs peuvent donc recevoir, à propos du même jeton, deux réponses légitimement différentes. La signature ne transforme pas la réponse la plus riche en modèle universel.

Deux aud, deux questions

Le serveur de ressources demande le format avec Accept: application/token-introspection+jwt. La réponse utilise le même type de média et le JWT porte typ: token-introspection+jwt. Son enveloppe doit contenir iss, aud, iat et token_introspection.

Le premier aud désigne le destinataire de la réponse d’introspection. Un aud à l’intérieur de token_introspection décrit l’audience du jeton inspecté. Le premier iat date la déclaration ; un iat interne appartient au cycle de vie du jeton. Confondre ces niveaux produit un logiciel qui vérifie le bon nom au mauvais endroit.

Le choix d’imbriquer sub, scope, exp et les extensions de RFC 7662 protège aussi la classification. RFC 9701 déconseille un sub ou un exp au niveau supérieur et précise que le JWT de réponse n’est pas une représentation de remplacement du jeton d’accès. Il ne doit jamais entrer dans le validateur d’accès comme une nouvelle créance porteuse.

Les registres OAuth de l’IANA, JWT et du type de média donnent des noms communs. Ils ne peuvent pas attester que l’implémentation a conservé le contexte de chaque nom.

Une signature a besoin d’un profil de vérification

La réponse peut être signée, ou signée puis chiffrée comme Nested JWT. Les mécanismes de JWS, JWE et JWT rendent la structure interopérable. Ils ne disent pas quels émetteurs le service local reconnaît, quelle clé était approuvée au moment de la décision, quel âge maximal est acceptable ni quelles erreurs doivent être fermées.

RFC 9701 ajoute des métadonnées pour les algorithmes de signature, de chiffrement de clé et de contenu. Le serveur d’autorisation peut annoncer ses possibilités via RFC 8414, tandis que le serveur de ressources enregistre ses clés de chiffrement. Une capacité annoncée n’est pas la preuve de l’algorithme réellement choisi. Un kid trouvé n’est pas encore une clé reliée au bon émetteur. Une signature valide n’est pas encore une audience, une fraîcheur ou une politique correcte.

Le compte rendu doit donc conserver l’octet exact de la réponse, le type, l’émetteur attendu, l’ensemble de clés et sa version, l’algorithme autorisé, le résultat de signature, le déchiffrement éventuel, l’audience et la règle temporelle. Sans cette chaîne, « JWT vérifié » masque plusieurs décisions.

La confusion inter-JWT est une erreur de juridiction

Un jeton d’accès encodé en JWT et une réponse d’introspection peuvent partager iss, aud et une signature du même domaine. Un validateur générique qui accepte tout JWT signé permet alors de présenter la réponse à la place d’un jeton d’accès. RFC 9701 impose le typ dédié et l’objet imbriqué ; RFC 8725 généralise cette discipline de typage explicite.

Le contrôle ne consiste pas seulement à chercher un champ. Chaque profil doit exiger son type, ses claims minimaux, son émetteur, son audience et ses algorithmes. Les profils doivent être mutuellement exclusifs. Déchiffrer correctement un objet ne l’autorise pas à changer de nature.

La réponse ne résout pas davantage le rejeu du jeton d’accès. RFC 9701 renvoie à RFC 9700. La contrainte d’émetteur, la preuve de possession, la liaison de requête et les contrôles de rejeu restent des faits séparés. Un serveur peut recevoir une déclaration authentique sur un jeton que le présentateur n’est pas autorisé à utiliser ici.

active:true vieillit sans perdre sa signature

Le iat extérieur rend l’âge mesurable, mais ne fixe pas une durée de cache universelle. Après la création de la réponse, le jeton peut expirer, être révoqué ou perdre une portée. Une règle de risque locale peut aussi changer. La signature historique restera valide : elle prouvera ce que le serveur d’autorisation disait alors. Elle ne conservera pas automatiquement l’autorité opérationnelle de la réponse.

La politique doit associer un âge maximal à chaque classe d’opération. Lire un profil et virer des fonds ne peuvent pas nécessairement partager la même tolérance. Au-delà du seuil, il faut une nouvelle introspection ou un autre mécanisme. Un cache performant sans règle de fraîcheur devient une source de droits fantômes.

Puis vient le jugement local. Une portée write ne dit pas si cet objet est verrouillé, si le compte est suspendu, si la transaction demande une approbation supplémentaire ou si une restriction territoriale s’applique. Le serveur de ressources produit son propre verdict. L’exécution produit encore une autre preuve : un allow suivi d’une panne de base de données n’est pas une modification réalisée.

Chiffrer les données ne fonde pas leur divulgation

La réponse peut contenir des données personnelles. RFC 9701 exige une base juridique et une limitation liée au destinataire. Le chiffrement empêche un tiers dépourvu de clé de lire le contenu ; il ne rend pas légitime un destinataire incorrect, ne minimise pas les champs et ne contrôle pas la réutilisation après déchiffrement.

L’introspection révèle également au serveur d’autorisation quand un utilisateur emploie une ressource. Si cette observation est inacceptable, le texte demande un autre mode de transmission des données de jeton. RFC 9325 protège le transport TLS ; il n’efface pas ce signal d’usage.

La preuve utile relie donc l’empreinte du jeton, l’identité du serveur appelant, son authentification, l’endpoint, le TLS, le type de réponse, la clé, la signature, l’enveloppe, l’objet interne, la base de divulgation, l’antirejeu, la règle locale et l’effet. Chaque élément répond à une autorité différente.

La doctrine de spécification initiale minimale de Lu Heng conserve cette répartition : le standard commun fixe le format, le type, les claims obligatoires et les métadonnées nécessaires à l’interopérabilité ; l’âge, la confiance, la vie privée, l’autorisation et l’exécution restent locaux. Les couches de réalité empêchent le registre, la signature, l’état du jeton, la décision et l’effet de se certifier mutuellement. La primauté du code en fonctionnement privilégie enfin la trace réelle du validateur et de l’application sur une simple promesse de prise en charge.

Sources