Dynamic Client Registration déprécié : passer aux Client ID Metadata Documents

Le Dynamic Client Registration OAuth 2.0 est formellement déprécié par la spec MCP 2026-07-28, au profit des Client ID Metadata Documents. Il continue de fonctionner pour la compatibilité descendante, mais il a une date.

Si tu opères un serveur MCP avec OAuth, ce chantier n'est pas urgent. Il vaut quand même la peine d'être compris maintenant, parce qu'il règle un problème que tu as probablement déjà.

Pourquoi le DCR posait problème

Dans le monde MCP, un client découvre des serveurs qu'il n'a jamais vus. OAuth classique suppose l'inverse : un client connu, enregistré à la main par un humain, une fois.

Le DCR a servi de rustine. Le client s'enregistre lui-même, à la volée, et reçoit un identifiant. Ça marche, et ça produit trois effets désagréables pour l'opérateur du serveur.

Une table qui grossit sans fin. Chaque installation crée un enregistrement. Sur un serveur public, ça devient des milliers de lignes dont la plupart ne resserviront jamais.

Aucune continuité d'identité. Le même client, réinstallé, revient avec un nouvel identifiant. Tu ne peux ni le reconnaître, ni lui appliquer une politique, ni le bannir durablement.

Une surface d'abus. Un endpoint d'enregistrement ouvert est un endpoint d'écriture ouvert. Il faut le limiter, le surveiller, et nettoyer derrière.

Ce que changent les Client ID Metadata Documents

L'idée est de retourner le problème : au lieu que le client demande un identifiant au serveur, il en apporte un qui est déjà vérifiable.

L'identifiant du client devient une URL, et cette URL sert un document qui décrit le client : son nom, ses URI de redirection, son type d'application. Le serveur d'autorisation récupère ce document au lieu de créer un enregistrement.

Les conséquences pour toi :

• Plus d'appel d'enregistrement à accepter, donc plus d'endpoint d'écriture ouvert
• Une identité de client stable dans le temps, la même partout, que tu peux journaliser et sur laquelle tu peux appliquer une politique
• Les métadonnées appartiennent au client et suivent ses mises à jour, tu n'héberges plus une copie qui périme

Pour les détails exacts du format et de la récupération, réfère-toi à la spécification plutôt qu'à un article, y compris celui-ci. C'est une partie du protocole qui bouge encore.

Ce que ça implique quand même de valider

Récupérer un document à une URL fournie par un tiers, c'est une requête sortante déclenchée par une entrée non fiable. Les précautions habituelles s'appliquent :

• N'accepte que HTTPS
• Bloque les adresses internes et le réseau local, sinon tu as construit un SSRF
• Impose un timeout et une taille maximale
• Mets en cache avec une durée raisonnable, et prévois ce qui se passe quand le document devient inaccessible
• Vérifie que les URI de redirection du document correspondent bien à celles utilisées dans le flux

Ce dernier point est le cœur de la sécurité du mécanisme. Le reste est de l'hygiène de client HTTP.

Le plan de transition

1. Continue d'accepter le DCR, il reste valable pendant la fenêtre de dépréciation
2. Ajoute la prise en charge des Client ID Metadata Documents à côté
3. Instrumente : compte combien d'enregistrements arrivent par chaque voie
4. Quand la part du DCR devient marginale, annonce une date de fin à tes intégrateurs
5. Nettoie la table d'enregistrements dynamiques, elle ne servira plus

Le point 3 est celui qui évite les décisions au feeling. Tu ne coupes pas le DCR parce que la spec le déprécie, tu le coupes quand tes chiffres disent que ça ne casse plus personne.

FAQ

Est-ce que je dois faire ça maintenant ?

Non. La politique de cycle de vie garantit une fenêtre d'au moins douze mois pour les fonctionnalités dépréciées. Traite d'abord le transport et les trois changements OAuth de la 2026-07-28.

Et si mes clients n'hébergent pas de document ?

Ils restent sur le DCR pendant la fenêtre. C'est précisément pourquoi la transition se fait en acceptant les deux.

Est-ce que ça change quelque chose pour mes utilisateurs finaux ?

Rien de visible. C'est un changement de plomberie entre le client et le serveur d'autorisation.

Tu ne veux pas suivre ces échéances toi-même

La veille de conformité, c'est 290 € par mois : je surveille les évolutions du protocole, je te dis ce qui concerne ton serveur, et je te préviens avant que ça devienne urgent.

Intéressé ? Discuter de la veille de conformité →

Lectures liées

• OAuth pour serveurs MCP : les trois changements de 2026-07-28
• Mettre en place une veille de conformité MCP sans équipe protocole
• Migrer un serveur MCP vers la spec 2026-07-28 : le guide complet