Résumé

  • RFC 9728 permet à une ressource protégée de publier les informations nécessaires à l’interaction ; cette publication n’accorde pas l’accès.
  • L’identité exacte de la ressource conditionne l’usage du document. L’émission puis l’acceptation d’un jeton et l’effet d’une opération restent indépendants.

Une équipe voit un authorization_servers dans un document et conclut parfois : « le chemin d’accès est validé ». Cette conclusion ajoute quatre décisions qui n’ont pas eu lieu. Le serveur nommé peut refuser le client. Un jeton éventuel peut viser une autre audience. Le serveur de ressources peut le rejeter. L’action peut échouer après une validation parfaite.

RFC 9728 rend la première étape plus sûre sans prétendre résoudre les suivantes. Une ressource publie un JSON à une adresse .well-known dérivée de son identifiant. Elle peut annoncer des serveurs d’autorisation, des scopes et des modes bearer. C’est une carte de l’interopérabilité, pas une délégation de l’autorité de la ressource.

La carte est utilisable seulement si elle correspond exactement au territoire annoncé. Le champ obligatoire resource doit être identique à l’identifiant dont a été dérivée l’adresse de métadonnées. Si l’URL a été fournie par WWW-Authenticate, il doit être identique à l’URL demandée au serveur de ressources. Sinon, le client ne doit pas utiliser les données. Un même domaine ou une route ressemblante ne suffit pas.

Cette exigence empêche qu’un document emprunte l’autorité d’une autre ressource. Elle compte lorsque plusieurs chemins ou locataires partagent un hôte : le suffixe well-known est inséré avant le chemin pour distinguer les ressources. Le document n’est donc pas une déclaration générale sur l’hôte.

Les listes ne constituent pas davantage un registre exhaustif de droits. Une ressource peut omettre des serveurs pris en charge dans authorization_servers et des scopes dans scopes_supported. Une valeur publiée informe; elle ne remplace pas la demande, l’évaluation, l’émission ni le contrôle de l’audience. Les métadonnées signées ajoutent l’attestation d’un émetteur sur ce paquet, non une authentification du client ou une autorisation métier.

La chaîne à conserver est longue : URL de ressource, URL de métadonnées, validation exacte, serveur choisi, résultat d’autorisation, jeton, validation côté ressource, préconditions applicatives et effet observé. RFC 8414, RFC 8707 et RFC 6750 confirment que ces contrôles appartiennent à des surfaces différentes. RFC 9728 ne les fusionne pas.

Sources