Résumé

  • Dans la RFC 9767, « actif » est une conjonction contextualisée : émetteur, révocation, temps, preuve, destinataire et accès demandé doivent tous convenir.
  • Le serveur d’autorisation produit un fait de validation. Le serveur de ressources contrôle encore la requête présente, applique sa propre règle et choisit sa réponse.
  • Une exploitation défendable conserve séparément la réponse d’introspection, la preuve de cette requête, la décision locale et l’effet observé, avec l’âge du cache et chaque délégation aval.

Le vrai objet de l’introspection

Le client apporte un jeton à un serveur de ressources, le RS. Ce dernier ne demande pas au serveur d’autorisation, l’AS, une permission abstraite valable partout. Il signe une requête en son propre nom et fournit un contexte : la valeur du jeton, la méthode de preuve utilisée lors de la présentation, son identité de RS et, s’il le souhaite, le niveau d’accès minimal nécessaire.

La distinction est décisive. Le même jeton peut convenir à un service et non à un autre, autoriser une lecture mais pas une écriture, être encore dans sa fenêtre temporelle tout en étant présenté avec une preuve inadéquate. L’AS doit tenir compte de tous les paramètres fournis. S’il ne sait pas traiter l’un d’eux, il ne doit pas répondre que le jeton est actif.

La RFC 9767 complète ainsi le cœur de GNAP sans fusionner les rôles. Le protocole principal organise la négociation du grant entre client et AS. L’extension traite les échanges entre AS et RS lorsque ces composants ne partagent ni processus ni base de données. L’interopérabilité porte sur le message ; elle ne transfère pas automatiquement la maîtrise de la ressource.

L’enrôlement de la clé du RS reste par ailleurs hors du périmètre. Une signature correcte prouve la possession de la clé reconnue par le dispositif choisi. Elle ne prouve pas que l’enrôlement était légitime, que les ressources ont été correctement attribuées au RS ni que sa décision future sera juste.

« Actif » est une phrase à six propositions

La valeur positive réunit plusieurs conditions. Le jeton doit avoir été émis par l’AS qui traite l’appel, ne pas être révoqué, ne pas être expiré, être lié selon la méthode de preuve indiquée, être destiné au RS identifié et satisfaire l’accès demandé lorsque ce champ est présent.

Cette définition interdit deux raccourcis symétriques. Un false ne signifie pas nécessairement « révoqué » : il couvre aussi l’expiration, une mauvaise audience, une preuve inadaptée ou l’impossibilité de statuer, notamment si le jeton n’est pas trouvé. Et un true ne signifie pas « opération approuvée » : il ne dit rien, à lui seul, sur le contenu de la requête, l’état de l’objet, une limite métier, une fraude, un consentement actuel ou le résultat final.

Quand la réponse est positive, l’AS peut renvoyer des droits, une clé, des drapeaux et des bornes temporelles. Mais les droits peuvent être filtrés pour ce RS, voire former une liste vide. La valeur du jeton elle-même ne doit pas réapparaître dans la réponse. L’AS fournit donc une vue utile et volontairement partielle, non un dossier universel.

Une journalisation réduite à « actif = oui » détruit ce périmètre. Il faut au minimum conserver l’AS interrogé, l’identité et la clé du RS, un condensat protégé du jeton, la méthode de preuve, l’accès demandé, les temps de requête et de réponse, les champs révélés et la décision de mise en cache.

Le RS garde la main

Le passage le plus important de la RFC vient après l’introspection : le RS détermine la conduite appropriée. Si les droits sont insuffisants, il peut produire une erreur ou servir une ressource publique. La réponse finale relève de son appréciation.

Il ne s’agit pas d’un défaut de sécurité. C’est la bonne localisation de l’autorité. L’AS connaît le grant, l’émetteur et l’état du jeton. Le RS connaît la méthode HTTP, la ressource concrète, son état, les obligations locales, les contrôles de sécurité et les réponses qu’il sait réellement exécuter.

Cette autonomie appelle une trace, pas une immunité. La décision doit nommer l’opération, la ressource, les droits pris en compte, la règle locale, sa version, les contrôles additionnels et la réponse choisie. Une ressource publique retournée après un jeton insuffisant ne doit pas devenir, dans un rapport, une « autorisation réussie ».

L’effet forme encore une autre étape. Un RS peut accepter une écriture puis perdre la transaction aval. Il peut commettre le changement sans que la réponse atteigne le client. Un code HTTP peut envelopper une erreur applicative. Le verdict du jeton ne prouve aucune de ces issues.

Deux validations, deux durées de vie

Pour un jeton lié à une clé, la validation du jeton et celle de la preuve de possession sont complémentaires. Une signature valide ne donne pas davantage de droits que le jeton ; un jeton actif ne garantit pas que le message courant porte la preuve attendue.

La RFC demande de vérifier la preuve pour chaque requête au RS. La cible, le contenu couvert et les paramètres de fraîcheur peuvent changer. Le résultat d’une preuve obtenue sur un message ne doit pas être réutilisé pour le suivant. Les signatures de messages HTTP, DPoP ou les jetons liés à un certificat illustrent différents moyens de lier une présentation ; aucun ne prend la décision applicative à la place du RS.

Il faut donc rattacher chaque preuve au message exact : composants signés, clé, algorithme, nonce ou horodatage, résultat et motif d’échec. Le tableau de bord qui ne conserve qu’un drapeau « jeton actif » ne permet pas de démontrer que la requête exécutée était celle qui avait été prouvée.

Le cache emprunte l’autorité du passé

Une introspection distante coûte du temps et crée une dépendance de disponibilité. Le RS peut mettre en cache le résultat. La RFC expose clairement le prix : moins de calcul et de latence, mais une information moins vivante et moins exacte. Un jeton révoqué peut rester accepté pendant la durée d’un résultat positif périmé.

Le choix du TTL appartient donc au RS et à l’organisation qui exploite la ressource. Dire « l’AS l’avait déclaré actif » ne déplace pas ce choix. Un cache de dix minutes signifie que le RS accepte de substituer pendant dix minutes un fait ancien à une interrogation actuelle.

La clé de cache doit préserver le contexte : jeton, RS, méthode de preuve et accès demandé lorsque celui-ci conditionne la réponse. Une entrée indexée uniquement par le jeton élargit silencieusement un verdict étroit. Les réponses négatives demandent aussi de la retenue, puisque false agrège refus certain et indétermination.

La révocation OAuth décrit un acte côté AS ; elle ne prouve pas l’invalidation de chaque cache. La RFC 9767 mentionne un signal proactif possible mais le laisse hors périmètre. L’accusé utile doit donc montrer quand une entrée a été invalidée, par quelle source, et quelle décision ultérieure a effectivement changé.

Voir moins, révéler autrement

L’introspection permet à l’AS de ne rendre au RS que les attributs pertinents. C’est une défense contre le partage excessif : un service non médical n’a pas à recevoir l’identifiant médical inclus pour un autre service. Mais chaque appel d’introspection informe l’AS qu’un jeton donné est utilisé sur un RS donné à un instant donné.

Le jeton structuré inverse une partie du compromis. Il autorise une validation locale et réduit la visibilité en temps réel de l’AS, mais peut exposer davantage de claims aux RS qui le lisent et conserver plus longtemps un état révoqué. La RFC admet jetons structurés, opaques et modèles mixtes. Le choix doit donc annoncer son budget de fraîcheur et son budget de divulgation.

La nature de la clé compte également. Une réponse qui fournit une clé publique asymétrique n’offre pas le secret nécessaire pour fabriquer une nouvelle présentation. Avec une clé symétrique, le RS reçoit le secret partagé et peut potentiellement produire lui-même une requête. Le mot « lié » ne décrit pas à lui seul le risque de réutilisation.

La référence de ressources suit la même logique de modestie. Elle représente un ensemble de ressources enregistré, mais doit rester opaque au client et au RS. Une valeur aléatoire ou chiffrée évite de révéler l’architecture et d’inciter les logiciels à dépendre d’une structure cachée. C’est un pointeur de coordination, pas un droit autonome.

Le jeton aval n’est pas une preuve de bout en bout

Lorsqu’un RS1 doit appeler un RS2, transmettre le jeton entrant est souvent la mauvaise réponse. RFC 9767 permet à RS1 de demander un jeton dérivé : il présente existing_access_token, s’identifie comme nouveau client avec sa propre clé et signe la demande. L’AS vérifie que le jeton entrant convenait à RS1, puis peut émettre un artefact plus étroit, lié à RS1 et destiné à RS2.

Cette dérivation limite la réutilisation d’un bearer token et clarifie l’audience. Elle ouvre cependant une nouvelle jambe de responsabilité. Le nouveau jeton ne prouve ni que RS1 a fidèlement compris la requête initiale, ni que RS2 a exécuté l’action, ni que RS1 a restitué le résultat exact au client.

Le mécanisme de token exchange d’OAuth offre une comparaison utile : un nouvel artefact réorganise sujet, acteur, audience et portée. Il ne fabrique pas une preuve d’effet. Pour chaque saut, il faut relier la requête entrante, la dérivation, l’émission, la présentation aval, la décision locale et l’effet observé.

Le test des quatre reçus

Une équipe peut éviter l’inflation d’autorité en refusant l’événement générique « autorisé ». Le premier reçu est l’introspection et son contexte. Le deuxième est la preuve liée au message courant. Le troisième est la décision du RS et sa politique. Le quatrième est l’effet : commit, réponse aval, livraison ou annulation.

Les essais doivent casser les jointures : mauvais RS, accès trop large, paramètre inconnu, preuve rejouée, positif en cache après révocation, liste de droits filtrée vide, perte de réponse après commit, réutilisation aval d’un jeton entrant. Le succès n’est pas que tout devienne vert. C’est que chaque composant échoue dans son propre périmètre sans inventer le reçu suivant.

Sources