Un assistant peut dire qui il est sans s’enregistrer
Connecter un assistant supposait qu’il s’enregistre d’abord ici, et Claude fabriquait un nouveau client à chaque connexion. Il peut désormais s’identifier par un document de métadonnées — une adresse qu’il publie et que ce serveur lit —, ce que la spécification MCP préfère. L’enregistrement continue de servir aux clients qui ne savent rien faire d’autre.
La page d’approbation a changé avec lui. Elle indique maintenant où la description d’un client est publiée, et avertit lorsque le seul endroit où il peut vous renvoyer est un programme installé sur votre propre ordinateur, car tout ce qui tourne là peut demander la même chose.
Un client dispose de trois moyens de dire à un serveur d’autorisation qui il est : s’enregistrer, être inscrit à la main, ou publier un document à une adresse et se servir de cette adresse comme nom. Ce serveur lit désormais le troisième.
Ce qu’est un document de métadonnées
Son client_id est une URL https. Le document qui se trouve à cette adresse dit comment le client s’appelle, où il peut être renvoyé et, s’il le souhaite, ce qu’il demande. Le serveur va le chercher pendant que vous autorisez, au lieu de tenir un enregistrement à lui. C’est draft-ietf-oauth-client-id-metadata-document-00 dans la lecture qu’en fait la spécification d’autorisation MCP du 25 novembre 2025, et Claude le préfère dès qu’un serveur annonce le prendre en charge.
Ce qu’il remplace
L’enregistrement dynamique de client (RFC 7591) fabrique ici un client à chaque connexion. Reconnecter le même assistant en produisait un autre, si bien que la table portait cinq lignes nommées « Claude » — impossibles à distinguer les unes des autres, et d’un inconnu enregistré sous le même nom. Un document publié a une adresse, et l’adresse est l’identité : ce qu’il dit peut changer, ce qu’il est, non. L’enregistrement continue de fonctionner, car il existe des clients qui ne savent faire que cela.
Ce que le serveur va chercher, et ce qu’il refuse
Ici, un client_id est une URL remise par un inconnu puis appelée par notre serveur : une falsification de requête côté serveur qui n’attend qu’une écriture négligente. Donc : https uniquement ; un chemin, car une origine nue désigne un hôte et non un client, et quiconque peut déposer un fichier à la racine d’un domaine parlerait sinon pour le domaine entier ; ni fragment ni identifiants ; l’URL sous forme canonique, et répétée à l’intérieur du document qu’elle nomme. Les redirections ne sont pas suivies, l’adresse est résolue puis refusée si elle est privée, un délai propre tient dans celui que le client accorde à l’ensemble, la taille est plafonnée à 64 KB, et le corps doit être du JSON avant d’être lu. Les réponses sont gardées une heure au plus et les échecs une minute : un client_id qui répond 404 ne transforme pas chaque appui sur le bouton en nouvel appel.
Ce que la page d’approbation en dit
Où la description du client est publiée, et qu’elle vient d’être lue. Et un avertissement lorsque toutes les adresses de retour possibles sont des programmes installés sur votre propre machine : le document est publié par le vrai client, mais ouvrir un port suffit à intercepter le code qui revient, et aucune page ne peut distinguer deux programmes de votre ordinateur. Ce jugement-là vous revient.
Autres lectures : convertir des documents depuis un assistant et convertir des documents avec une API.