Résumé

  • draft-mcguinness-oauth-client-attesters-00 propose le paramètre client_attesters, qui associe dans les métadonnées d’un client un issuer exact à un jwks_uri. La révision 00 reste un Internet-Draft individuel, sans statut de RFC.
  • Deux accords sont indispensables : l’éditeur du client autorise un attestateur à parler pour ce client, puis le serveur d’autorisation décide indépendamment s’il lui fait confiance et quelle source de clés est recevable.
  • Retirer l’endossement n’annule ni les grants ni les tokens existants. L’effet dépend des caches, de la politique locale et des serveurs de ressources qui valident directement les attestations.

Le changement paraît banal : un opérateur remplace l’adresse d’un jeu de clés dans la fiche d’un client. L’attestateur signe déjà avec la nouvelle clé. Pourtant le serveur d’autorisation refuse l’attestation. Ce refus n’est pas une panne de cryptographie ; il protège un désaccord d’autorité. La valeur publiée ne correspond ni à la source configurée par le serveur ni à un alias explicitement approuvé.

C’est la contribution la plus intéressante du projet OAuth 2.0 Client Attester Endorsement. ATTEST décrit la preuve fournie par une instance de client et la possession de sa clé, mais laisse hors de son périmètre le lien « cet attestateur peut parler pour ce client_id ». Le nouveau texte place ce lien dans les métadonnées autoritatives du client, sous la forme d’un tableau client_attesters.

Chaque entrée contient l’issuer attendu dans iss et un jwks_uri HTTPS. L’éditeur affirme ainsi son choix de mandataire. Il n’impose pas une racine de confiance au serveur d’autorisation, ne crée aucun droit d’accès et ne délègue pas l’autorité d’un utilisateur.

Deux autorités doivent se rencontrer

Pour accepter l’attestation, le serveur doit d’abord constater que la source de métadonnées retenue pour le client_id endosse actuellement l’émetteur. Sa propre politique doit ensuite autoriser l’association client-attestateur et déterminer la provenance des clés.

La symétrie est volontaire. Un éditeur ne peut rendre fiable un attestateur par simple publication. Un serveur qui fait confiance à un attestateur ne peut l’ajouter à un client qui ne l’a pas nommé. La politique locale peut réduire l’ensemble publié, jamais l’élargir pour une requête gouvernée par ce profil.

Le premier modèle, publisher-authorized key selection, autorise au préalable l’éditeur à choisir l’attestateur et sa source de clés. Le serveur récupère alors le jwks_uri endossé, avec des contraintes HTTPS, d’origine et de chemin. Le modèle passe à l’échelle, mais l’assurance ne dépasse pas l’éditeur : celui qui contrôle le document CIMD peut aussi présenter son propre attestateur.

Le second modèle, AS-configured attester trust, conserve une source de clés configurée indépendamment pour l’issuer exact. Le jwks_uri publié doit lui être identique ou correspondre à un alias explicite ; il n’est pas utilisé comme adresse de repli. Le désaccord provoque un échec, précisément pour qu’aucun acteur ne prenne silencieusement la place de l’autre.

Une subtilité élargit le risque opérationnel. Dès qu’un issuer exact possède une confiance configurée pour un client, ce régime s’applique à cet issuer pour tous les clients. Supprimer la configuration ne remet pas automatiquement la sélection aux éditeurs. Les alias sont eux aussi globaux à l’issuer. Une modification présentée comme locale peut donc toucher de nombreux clients.

L’ordre de validation fait partie de la sécurité

Le serveur choisit une seule source autoritative de métadonnées. Il ne fusionne pas inscription et CIMD et ne change pas de source après un échec. Il cherche ensuite l’unique entrée dont issuer égale exactement iss, applique la politique, choisit la source de clés et résout kid vers une seule clé publique asymétrique admissible.

La clé doit rester liée au quadruplet client, issuer, source et politique. kid seul ne suffit pas ; agréger les clés de plusieurs entrées détruirait la séparation. Les en-têtes jku, x5u, x5c et jwk de l’attestation ne pilotent pas la sélection. Viennent seulement ensuite la signature, l’égalité exacte sub == client_id, la preuve de possession et les autres contrôles ATTEST.

L’autorisation reste une décision ultérieure. Une attestation valide ne choisit ni la portée, ni la ressource, ni l’opération commerciale. Elle répond à une question d’identité et d’assurance ; le grant répond à une question de pouvoir.

Un retrait se propage, une révocation agit

L’éditeur retire un attestateur en supprimant son entrée. Tant qu’une copie en cache reste fraîche, elle peut continuer d’être utilisée. Le projet impose un âge maximal fini, mais n’en fixe pas la valeur. Le délai prévisible doit donc être négocié et mesuré.

Une réponse 404 ou 410 observée impose d’abandonner les métadonnées ou clés en cache. Un timeout ou un 5xx ne rend pas invalide une copie non expirée. Le système qui lit son cache ne peut pas encore savoir que le document distant a disparu.

La rotation planifiée ajoute une autre chronologie : publier la nouvelle clé, attendre la durée des caches, commencer à signer, puis conserver l’ancienne jusqu’à expiration des attestations. Un changement d’URL exige aussi le rafraîchissement des métadonnées et, dans le mode configuré, l’accord de l’opérateur du serveur.

Surtout, le retrait est prospectif. Il bloque les authentifications futures une fois observé ; il ne révoque aucun grant ni access token. Mettre fin à l’accès demande de révoquer séparément grants et tokens, d’empêcher le refresh, de rendre l’introspection inactive et d’attendre ou traiter les tokens validés hors ligne. Un serveur de ressources qui valide directement une Client Attestation dépend de sa propre configuration : ce profil ne lui transmet pas le retrait.

La preuve utile est une trace de décisions

Le reçu d’exploitation doit nommer le client_id, la source autoritative unique, son hash, son âge et son échéance. Il conserve l’endossement exact et la preuve que l’éditeur pouvait le publier. Il indique ensuite le mode de confiance, sa priorité, la source de clés, les alias, le hash du JWK Set, sa fraîcheur, le kid, l’algorithme et l’unique clé retenue.

Après le résultat de l’attestation et de la preuve, il faut préciser si l’attestation était obligatoire. La seule présence de client_attesters ne l’impose pas ; un signal facultatif peut être écarté au profit d’une autre méthode d’authentification. Enfin, le reçu consigne la décision de grant séparée.

En phase de retrait, la trace ajoute l’heure d’observation, la convergence des caches, la dernière présentation acceptée, l’expiration des attestations, la révocation des tokens, le refus du refresh, l’état d’introspection et les validateurs directs. Ce modèle est une proposition éditoriale de Daniel Kade, pas une exigence normative du draft.

L’erreur publique invalid_client_attestation reste volontairement opaque. Elle ne dit pas si l’endossement manque, si l’éditeur n’a pas le droit de choisir les clés, si les sources divergent ou si la récupération a échoué. Les journaux privilégiés doivent, eux, préserver cette différence : fabriquer une nouvelle attestation ne résout pas un conflit de politique.