Autorisation MCP 2026-07-28 : vérification de l'émetteur et évolution de l'enregistrement des clients

Ce que c'est

État au 25 octobre 2026. Les changements relatifs à l'autorisation dans 2026-07-28 concernent la validation de l'émetteur, l'enregistrement et le rattachement des identifiants d'authentification. Vérifier de nouveau la spécification versionnée de l'autorisation, les règles d'enregistrement et les métadonnées du serveur d'autorisation avant le déploiement. Les Client ID Metadata Documents (CIMD) ne sont pas introduits ici : le journal des modifications de 2025-11-25 les recommande déjà. La nouvelle révision déprécie formellement Dynamic Client Registration (DCR), tout en le conservant pour la compatibilité.

Le serveur MCP est la ressource protégée, le client MCP obtient l'accès et le serveur d'autorisation émet les jetons. Les modifications peuvent donc concerner différents services, même lorsqu'un seul exploitant les gère tous. Le cadre OAuth de MCP s'applique aux déploiements HTTP ; il ne constitue pas le mécanisme d'authentification prescrit pour stdio.

Pourquoi c'est important

Un flux d'autorisation doit rester associé à l'émetteur sélectionné lors de son lancement. Sinon, des changements de points de terminaison ou des données d'enregistrement ambiguës peuvent conduire à utiliser des identifiants d'authentification auprès du mauvais serveur d'autorisation. CIMD introduit également des responsabilités de récupération de documents et de validation des redirections ; reconnaître un identifiant de client sous forme d'URL ne suffit pas à établir la confiance dans l'application.

Comment l'appliquer

• Valider les réponses d'autorisation avant d'échanger le code. Les clients enregistrent l'émetteur issu des métadonnées validées du serveur avec le vérificateur PKCE de la tentative d'autorisation. Les serveurs d'autorisation devraient renvoyer iss et doivent annoncer cette prise en charge lorsqu'ils le font. Les clients comparent exactement tout iss renvoyé à la valeur enregistrée après décodage du formulaire, sans normaliser l'URL. Toute divergence entraîne un rejet, y compris pour les réponses d'erreur. Si les métadonnées annoncent la prise en charge du paramètre d'émetteur mais que iss est absent, rejeter la réponse ; si cette prise en charge n'est pas annoncée et que le paramètre n'est pas fourni, la spécification autorise la poursuite du processus.
• Lier les identifiants d'enregistrement à l'émetteur. Stocker les identifiants issus d'un préenregistrement ou de DCR sous l'identifiant du serveur qui les a émis. Ne jamais les réutiliser auprès d'un autre émetteur. Obtenir un enregistrement pour le nouveau serveur ; en cas de préenregistrement incompatible, signaler une erreur. Cette règle ne rend pas un identifiant CIMD auto-hébergé propre à un émetteur : la spécification d'enregistrement permet explicitement la portabilité de cet identifiant URL sans nouvel enregistrement.
• Respecter les règles de choix de l'enregistrement. Privilégier le préenregistrement disponible, puis CIMD lorsque sa prise en charge est annoncée par client_id_metadata_document_supported, puis DCR s'il est pris en charge, comme solution de repli pour la compatibilité. Un document CIMD utilise HTTPS avec un chemin et contient client_id, client_name et redirect_uris. Son client_id doit être égal à l'URL du document ; valider le JSON et vérifier la redirection demandée par rapport au document.
• Renforcer la récupération des métadonnées. Appliquer les protections documentées contre la falsification de requêtes côté serveur lors de la récupération des documents clients. Envisager des politiques de confiance par domaine. CIMD seul ne peut pas empêcher les usurpations impliquant des redirections vers localhost ; afficher le nom d'hôte de redirection pendant l'autorisation, comme exigé.
• Maintenir un fonctionnement correct de l'ancien mécanisme DCR. Les clients doivent préciser un application_type approprié. Les applications natives de bureau, en ligne de commande et sur localhost devraient utiliser native ; les applications distantes accessibles par navigateur devraient utiliser web. Rechercher la cause des échecs d'enregistrement au lieu d'assouplir les contrôles de redirection pour les faire disparaître.
• Conserver le niveau minimal de sécurité existant. Vérifier la prise en charge de PKCE dans les métadonnées, protéger les jetons stockés et valider que les jetons entrants sont destinés à cette ressource MCP. Les appels aux API en amont nécessitent des jetons distincts émis pour ces services. La migration de l'enregistrement n'autorise ni la transmission telle quelle des jetons ni la suppression des vérifications de consentement.

Pièges

Ne pas présenter DCR comme déjà supprimé, ni CIMD comme universellement obligatoire : sa prise en charge est une recommandation. Le test de recette proposé consiste à tester en préproduction les réponses dont l'émetteur est correct, différent ou absent, un changement d'émetteur et chaque méthode d'enregistrement conservée. Vérifier que les réponses rejetées ne parviennent jamais à l'étape d'échange du code. Ces contrôles visent la conformité au protocole ; ils ne constituent pas un audit de sécurité d'un déploiement d'autorisation particulier.