Résumé

  • Le projet draft-ietf-oauth-rar-metadata-remediation-00 permet à un serveur de ressources de joindre à un refus OAuth des objets RAR exploitables, que le client peut reprendre dans une nouvelle demande d’autorisation.
  • Le serveur de ressources formule ce qu’il juge suffisant, mais il n’accorde rien : le client choisit de poursuivre, le serveur d’autorisation applique sa politique et le titulaire de la ressource peut refuser ou réduire la demande.
  • Daniel Kade propose un registre d’écart d’autorité reliant la requête refusée, les droits existants, la proposition, le schéma utilisé, le consentement, les droits effectivement octroyés et l’effet final. Ce registre ne fait pas partie du protocole.

Le refus devient un document actif

Dans une intégration bancaire classique, un refus pour droits insuffisants laisse souvent deux possibilités peu satisfaisantes. Soit le client affiche une erreur générique, soit les équipes ont préparé hors bande une procédure spécifique à l’établissement, au type d’opération et à l’application. La première voie abandonne l’utilisateur. La seconde fonctionne, mais elle transforme chaque intégration en convention privée.

Le premier projet de groupe de travail sur les métadonnées RAR et la remédiation propose une troisième voie. Un serveur de ressources qui reçoit un jeton valide mais insuffisant peut répondre par insufficient_authorization. Le paramètre authorization_remediation transporte un objet JSON encodé en base64url. Il peut contenir des authorization_details construits à partir de la requête refusée ainsi qu’une authorization_reference opaque.

Le client dispose alors d’un parcours défini. Il peut chercher, dans le stockage de la session utilisateur, un jeton déjà associé à la même référence et à la même origine. Faute de candidat utilisable, il peut placer directement les détails fournis dans une nouvelle demande OAuth compatible avec RFC 9396. Après l’octroi, il réessaie l’appel à la ressource.

Le gain d’interopérabilité est net. RFC 9396 a normalisé une représentation structurée des droits fins, mais pas la découverte complète des types ni la réparation d’un appel refusé. Le nouveau texte ajoute un point de métadonnées avec schémas et exemples, un signal d’erreur et des règles de traitement.

Le statut institutionnel reste limité. La révision 00 date du 23 août 2026, remplace une série individuelle et figure comme document du groupe OAuth. Le compte rendu de l’IETF 126 montre un intérêt pour le problème, une discussion encore ouverte sur la solution et un appel à adoption. Il ne s’agit ni d’un RFC, ni d’une allocation IANA achevée, ni d’une preuve de déploiement.

Celui qui énonce la condition ne délivre pas le droit

Le point délicat tient à la précision du message. Les détails sont dits « exploitables » et le texte prévoit que leur présence dans un nouvel octroi réussi doit satisfaire les exigences de la ressource. Le serveur de ressources écrit donc une proposition qui peut devenir la matière première de la prochaine demande d’autorité.

Il ne devient pas pour autant serveur d’autorisation. Plusieurs décisions restent distinctes. Le client peut ignorer ou refuser le défi. Le serveur d’autorisation vérifie le type, la politique et le flux choisi. Selon RFC 9396, il présente les droits demandés au titulaire de la ressource, qui peut n’en accepter qu’une partie. La réponse de jeton expose les détails effectivement accordés. Enfin, le serveur de ressources contrôle encore si ce jeton permet l’opération concrète.

Cette chaîne interdit deux raccourcis. Dire « l’API s’est donné des droits » serait faux. Dire « ce n’était qu’une nouvelle tentative » le serait aussi. Une proposition d’autorité est entrée dans le système, éventuellement sans que l’interface en montre la différence avec la requête initiale.

Imaginons qu’un client ait tenté une consultation ponctuelle et que le serveur renvoie un objet autorisant une relation récurrente. Ou qu’un changement de contexte — localisation, état du terminal, risque de transaction — conduise à demander une cérémonie plus forte et des attributs supplémentaires. La proposition peut être équivalente, plus étroite, plus large ou incomparable. Un statut HTTP ne dit pas laquelle de ces situations s’est produite.

La taille du JSON ne le dit pas davantage. RFC 9396 souligne qu’il n’existe pas de comparaison universelle entre deux objets de détails : chaque API définit la sémantique de ses champs. Une valeur omise peut activer une règle par défaut ; une liste peut additionner des capacités ; un identifiant différent peut déplacer l’autorisation vers une autre ressource. La réduction du nombre d’octets n’est pas une réduction de pouvoir.

Une référence opaque reste une aide de sélection

L’authorization_reference répond à un problème pratique. Le client n’a pas besoin de comprendre un objet riche pour retrouver un jeton potentiellement adapté. Le serveur de ressources produit une chaîne stable pour des détails identiques ou sémantiquement équivalents ; le client compare cette chaîne à celles conservées dans la même session et pour la même origine.

Le texte borne soigneusement cet usage. La référence ne doit révéler aucune information sensible. Le client ne doit pas l’interpréter. Elle ne vaut pas auprès d’un autre serveur de ressources et ne doit pas être émise pour des jetons à usage unique.

Une correspondance n’est toutefois pas un verdict d’autorisation. Le consentement a peut-être été révoqué, le contexte de risque a pu évoluer, ou le serveur d’autorisation a pu ne délivrer qu’un sous-ensemble des droits sollicités. Le serveur de ressources doit refaire son contrôle.

L’inverse est tout aussi important. Deux références différentes ne prouvent pas deux niveaux ordonnés. Le projet donne l’exemple d’un jeton autorisant des débits récurrents jusqu’à 100, susceptible de convenir à une opération de 80 malgré une autre référence. L’inclusion repose sur la sémantique du type, pas sur l’égalité de chaînes opaques.

Un tableau de bord qui transforme « référence trouvée » en « autorisation validée » déplace donc la signification. Il ne sait qu’une chose : un candidat a été sélectionné. Un tableau de bord qui lance automatiquement un nouveau flux à chaque « référence différente » risque, lui, de masquer une succession de propositions de droits.

Le schéma ne décide pas de l’usage légitime

Le point de métadonnées proposé décrit chaque type par une version informative, une description, une documentation, des exemples et soit un JSON Schema intégré, soit l’URI d’un schéma. Le schéma doit valider un seul objet et contraindre le champ type à l’identifiant correspondant.

Cette mécanique améliore la syntaxe et la découverte. Elle ne répond pas à la question normative de l’usage. Le projet précise que la description ne sert ni à l’autorisation ni à la validation, que les exemples ne sont pas normatifs et que la version n’instaure pas de négociation sémantique. Un schéma valide peut décrire une demande excessive, mal expliquée ou étrangère au but poursuivi.

La provenance du schéma reste néanmoins indispensable. Si sa définition change entre le refus et le consentement, les mêmes champs peuvent être interprétés différemment. Il faut dater la récupération, conserver l’URI ou l’empreinte du schéma intégré, et identifier le moteur de politique qui a évalué l’objet.

Le choix de l’émetteur doit également rester visible. Si le serveur d’autorisation habituel ne prend pas en charge le type demandé, le client peut découvrir une solution de rechange via les métadonnées de ressource protégée. Changer d’émetteur n’est pas changer de simple destination réseau : les règles d’inscription, d’authentification, de consentement et de conservation peuvent différer.

Un registre d’écart d’autorité

Je propose un registre d’écart d’autorité. Il n’ajoute aucun champ au jeton et n’est pas une exigence de l’IETF. C’est une preuve d’exploitation qui conserve les décisions sans copier les secrets.

Au moment du refus, il lie la session utilisateur, l’origine du serveur de ressources, une empreinte de l’opération et les droits effectifs du jeton présenté. Pour les données sensibles, il retient des engagements salés ou des références à courte durée plutôt que des comptes, dossiers médicaux ou montants lisibles dans les journaux.

Il fige ensuite la proposition : empreinte du contenu décodé, résumé intelligible de l’effet demandé, référence opaque, type de détail, URI ou empreinte du schéma, version informative et date de récupération. Un évaluateur propre au type classe l’écart comme inchangé, plus étroit, plus large, incomparable ou inconnu. Sa version de politique fait partie de la preuve.

Le registre décrit ensuite le choix du client : abandon, réemploi d’un jeton, nouvelle autorisation, confirmation explicite ou examen humain. Il nomme le serveur d’autorisation retenu, la version de l’écran de consentement, la décision du titulaire et les détails réellement accordés. La différence entre proposition et octroi ne doit pas disparaître.

Enfin, il compte les tentatives, associe une référence à un jeton sans conserver le jeton, note la décision finale de la ressource et rattache l’opération à son résultat ou à son annulation. Une autorisation réussie n’est pas encore la preuve que le paiement, la lecture ou la modification a produit le résultat attendu.

Ce découpage rend les responsabilités lisibles. Le serveur de ressources prouve ce qu’il a proposé ; le client, ce qu’il en a fait ; le serveur d’autorisation, ce qu’il a présenté et délivré ; le titulaire, ce qu’il a accepté ; l’application, l’effet observé.

Éviter l’archive de données que l’audit prétend protéger

Les objets RAR peuvent contenir des informations bancaires, médicales ou transactionnelles. Le projet recommande de ne pas inclure de valeurs sensibles dans le défi et autorise des poignées opaques. Il demande aussi au serveur d’autorisation d’évaluer la confidentialité avant d’insérer les détails dans un JWT, l’introspection authentifiée offrant parfois une meilleure solution.

Le registre doit rester fidèle à cette retenue. Une empreinte non salée d’un montant prévisible n’est pas une anonymisation. Un résumé destiné à l’exploitation doit décrire la classe d’effet sans recopier le dossier. Les données détaillées, si elles sont indispensables, restent dans le domaine protégé et disparaissent selon une durée définie.

La provenance compte autant que la confidentialité. Un identifiant fourni par le serveur de ressources n’est pas une déclaration de l’utilisateur. Un texte de schéma n’est pas une preuve de consentement. Un détail inscrit dans le jeton ne prouve pas que l’interface était compréhensible. Conserver ces origines empêche l’audit de transformer des objets techniques en certitudes sociales.

Quand la remédiation devient automatisation de politique

Le projet limite les boucles : un essai avec un jeton en cache, une nouvelle autorisation, puis arrêt si la même référence revient. Une autre référence peut permettre une nouvelle tentative, dans une limite définie par l’implémentation. Le stockage doit rester séparé par session utilisateur.

Ces règles contrôlent la répétition mécanique. Elles ne jugent pas la progression de l’autorité. Plusieurs références successives peuvent représenter des ajustements légitimes, une politique instable ou un escalier de demandes plus puissantes. Il faut donc ajouter un budget sémantique : nouvel émetteur, type à fort impact, autre ressource, récurrence étendue, durée accrue, schéma modifié ou objet incomparable.

Au-delà de ce budget, l’application cesse de « réparer » silencieusement et explique la nouvelle décision. C’est le sens utile de la frontière. Réessayer consiste à répéter une opération avec une autorité déjà acquise. La remédiation RAR peut demander une autorité différente. L’interopérabilité gagne à transporter cette proposition ; la gouvernance exige d’en conserver l’écart.

Sources

  1. Projet OAuth RAR metadata et remédiation
  2. Historique du projet
  3. Révision 00
  4. Dépôt source du projet antérieur
  5. Compte rendu OAuth de l’IETF 126
  6. Mandat du groupe OAuth
  7. RFC 9396 — Rich Authorization Requests
  8. RFC 6750 — utilisation des jetons Bearer
  9. RFC 8414 — métadonnées du serveur d’autorisation
  10. RFC 9728 — métadonnées de ressource protégée
  11. RFC 9470 — défi d’authentification renforcée
  12. RFC 7662 — introspection de jeton
  13. RFC 9068 — profil JWT des jetons d’accès
  14. RFC 9126 — demandes d’autorisation poussées
  15. RFC 9101 — demande d’autorisation sécurisée par JWT
  16. Registres OAuth de l’IANA
  17. Fiche API du Datatracker
  18. Texte brut de la révision 00
  19. Source XML de la révision 00
  20. Tickets du dépôt antérieur