Résumé

  • La RFC 7662 permet à une ressource protégée de demander au serveur d’autorisation l’état présent d’un jeton et des métadonnées pertinentes pour elle.
  • active: true est une conclusion utile sur le jeton, mais ni une autorisation de l’action demandée, ni une preuve d’exécution, ni un reçu durable.
  • La mise en cache négocie la charge et la latence contre la fraîcheur ; l’état du jeton, la décision locale et l’effet applicatif doivent rester trois preuves distinctes.

Une réponse affirmative, mais à une question étroite

L’introspection intervient lorsque le serveur de ressources reçoit un jeton qu’il ne peut pas, ou ne souhaite pas, évaluer entièrement en local. Il le présente à un point de terminaison du serveur d’autorisation. La réponse contient obligatoirement le booléen active et peut fournir le périmètre, l’identité du client, le sujet, le type du jeton, ses bornes temporelles, son audience ou son émetteur.

Le oui est substantiel. Selon la RFC 7662, un jeton actif a généralement été émis par ce serveur d’autorisation, n’a pas été révoqué et se situe encore dans son intervalle de validité. Le serveur applique les contrôles pertinents : expiration, date de prise d’effet, révocation, signature, ainsi que l’aptitude du jeton à être employé auprès de la ressource protégée qui interroge. Réduire l’introspection à la disponibilité d’une API ferait perdre l’essentiel de cette garantie.

Mais cette garantie possède un territoire. Le serveur d’autorisation connaît le cycle de vie du titre d’accès. Il ne connaît pas nécessairement le solde d’un compte, le propriétaire actuel d’un document, le plafond quotidien, l’état d’un stock ou la version d’une ligne en base. Ces faits appartiennent à la ressource et à l’application.

Un jeton peut donc être actif et insuffisant pour la demande. Son périmètre peut sembler compatible, tandis qu’une règle de séparation des locataires, une obligation de réauthentification, une interdiction réglementaire ou une condition métier impose le refus. La bonne formulation est : le jeton peut participer à la décision. La mauvaise est : le serveur d’autorisation a déjà décidé l’opération.

L’interface attribuée à Richer ne déplace pas la responsabilité

Justin Richer est l’auteur nommé de la RFC 7662, document Standards Track de l’IETF consacré à l’introspection des jetons OAuth 2.0. Cette attribution doit rester exacte : il s’agit d’un travail normatif de l’IETF, non d’un pouvoir personnel sur les mises en œuvre ni d’une revendication d’invention solitaire de l’écosystème OAuth.

La structure du protocole met en relation deux autorités différentes. Le serveur d’autorisation possède l’information fiable sur l’émission du jeton, sa durée, sa révocation et la délégation qu’il représente. Le serveur de ressources possède la politique sur la méthode appelée, l’objet visé et les circonstances présentes. L’introspection fournit un pont entre eux ; elle ne fusionne pas leurs compétences.

Le cadre OAuth lui-même conserve cette répartition. Le client présente un jeton d’accès au serveur de ressources. Celui-ci le valide puis sert la requête si elle satisfait ses conditions. La RFC 6750 décrit ce mouvement pour les jetons au porteur. La RFC 7662 offre une méthode normalisée pour obtenir les éléments de validation, sans produire la règle métier qui transformera ces éléments en « autoriser » ou « refuser ».

Une piste d’audit sérieuse doit donc distinguer la conclusion du serveur d’autorisation de la décision de la ressource. Elle doit indiquer qui a interrogé, quand, avec quel contexte, puis quelle version de politique locale a tranché. Un unique événement « autorisé » est séduisant pour un tableau de bord, mais pauvre lorsqu’il faut expliquer une anomalie.

La réponse dépend aussi de son destinataire

La RFC 7662 n’exige pas que l’introspection divulgue le même dossier à tous. Le serveur d’autorisation peut adapter la réponse à la ressource protégée qui l’appelle. Il peut notamment limiter les périmètres retournés à ceux qui concernent ce destinataire. La confidentialité y gagne, et le sens de l’activité reste attaché à la ressource qui pose la question.

Cette possibilité interdit de traiter le résultat observé par une API comme une vérité universelle pour toutes les autres. Il faut conserver l’identité de la ressource appelante, l’audience, les champs révélés et l’heure de l’observation. Deux réponses différentes ne constituent pas forcément une incohérence ; elles peuvent refléter deux droits d’observer ou deux contextes d’utilisation distincts.

La RFC 8707 éclaire un autre partage. L’indicateur de ressource précise où le jeton est destiné à être utilisé, tandis que le périmètre exprime le type d’accès demandé. « Où » et « quoi » se complètent, mais ne disent toujours pas si l’action concrète respecte l’état et les règles de l’application.

Il en va de même des champs optionnels. exp et nbf bornent le temps ; aud et iss identifient audience et émetteur ; sub, username et client_id désignent des rôles qui ne se confondent pas toujours. Quant à jti, il identifie un jeton. Un même jeton pouvant servir à de nombreuses requêtes, cet identifiant ne devient ni numéro de commande ni clé d’idempotence.

La fraîcheur a un prix

Interroger le serveur d’autorisation à chaque appel augmente sa charge et ajoute une dépendance réseau au chemin critique. La RFC 7662 autorise donc la mise en cache des réponses. Elle en formule aussi franchement le coût : plus le cache dure, moins la réponse reflète en direct l’état du jeton.

Un service peut apprendre à 10 h 00 qu’un jeton est actif et conserver cette réponse cinq minutes. À 10 h 01, l’utilisateur révoque le jeton suivant la RFC 7009, ou un administrateur invalide la délégation. Jusqu’à l’expiration du cache, la ressource peut continuer à utiliser l’ancien verdict. Le serveur d’autorisation dit vrai sur l’état nouveau ; la ressource suit une information ancienne conformément à sa configuration.

Le TTL du cache devient ainsi une décision de sécurité. Il doit dépendre de la durée du jeton, de la promesse de révocation, de la sensibilité de l’opération, de la disponibilité attendue du serveur et du dommage possible pendant la fenêtre de retard. Une lecture peu sensible et une récupération de compte ne méritent pas automatiquement la même tolérance.

La révocation ne réécrit pas non plus le passé. La RFC 7009 rend un jeton inutilisable et peut entraîner l’invalidation d’éléments liés selon l’implémentation. Elle n’annule pas une somme déjà transférée, un secret déjà lu ou un message déjà livré. Le cycle du titre d’accès gouverne l’acceptation future ; la réparation des effets appartient à l’application.

Le dernier kilomètre n’est pas dans l’introspection

Même après une décision locale favorable, l’exécution peut rester ambiguë. Le serveur peut tomber avant la validation en base, ou réussir puis perdre sa réponse. Une file peut accepter une commande qu’un travailleur rejettera ensuite. Le client peut relancer avec le même jeton actif, et deux requêtes techniquement valides peuvent viser une seule intention humaine.

Aucun champ de l’introspection ne sert de reçu pour cette intention. Le périmètre décrit une classe d’accès. jti regroupe les usages d’un jeton, non une opération unique. Le succès de l’appel d’introspection prouve que des renseignements ont été fournis ; il ne prouve pas que la mutation demandée a eu lieu.

Pour les opérations à conséquence, l’application doit créer une identité durable : clé d’idempotence, identifiant de commande, précondition de version ou dispositif équivalent. Elle doit rendre le résultat consultable après une temporisation. Validation du jeton, décision de la ressource, identité de l’opération, validation de l’état et livraison de la réponse sont des enregistrements associables, mais non interchangeables.

Respecter le travail normatif de Richer revient précisément à ne pas le surcharger. La RFC 7662 donne une réponse solide à une question limitée et difficile. Lorsqu’une architecture préserve cette limite, elle sait enfin où demander les autres réponses.

Sources