Revue approfondie de la spécification d'autorisation MCP (édition du 2025-03-26)

MCP (Model Context Protocol) est une norme ouverte qui permet aux modèles d'IA d'interagir avec des outils et des services externes. Elle est largement adoptée par l'industrie. Comme MCP prend en charge les méthodes de transport basées sur HTTP, le serveur MCP distant jouera un rôle de plus en plus important dans l'écosystème MCP.

Contrairement au serveur MCP local, qui permet à chaque utilisateur de faire fonctionner sa propre instance de serveur, le serveur MCP distant exige que tous les utilisateurs partagent le même service de serveur MCP. Cela soulève le problème central que la spec d'autorisation MCP vise à résoudre : comment permettre au serveur MCP d'accéder aux ressources utilisateur pour le compte de l'utilisateur.

Cet article analysera en profondeur la spec d'autorisation MCP. Il vous aidera à comprendre les principes de conception de la spec d'autorisation MCP et certaines directions pour la mise en œuvre de l'autorisation MCP. Étant donné que cette spec est encore en évolution, je partagerai quelques réflexions basées sur mon expérience personnelle en matière de mise en œuvre d'authentificateur, y compris :

• Avantages et limitations d'OAuth 2.1 en tant que cadre d'autorisation
• Défis des doubles rôles du serveur MCP en tant que serveur d'autorisation et serveur de ressources
• Complexité pratique de la mise en œuvre d'un serveur d'autorisation complet
• Analyse des scénarios adaptés pour l'autorisation déléguée par des tiers
• Compromis pratiques de l'enregistrement dynamique des clients
• Importance de définir clairement les limites des ressources du serveur MCP

Aperçu de la spec d'autorisation MCP#

La spec d'autorisation MCP définit le processus d'authentification entre le serveur MCP (distant) et le client MCP.

Je pense que baser cette spec sur OAuth 2.1 est un choix très raisonnable. OAuth en tant que cadre de protocole d'autorisation résout le problème de la manière de permettre aux utilisateurs d'autoriser des applications tierces à accéder à leurs ressources pour leur compte. Si vous n'êtes pas familier avec OAuth, vous pouvez consulter AuthWiki-OAuth pour plus d'informations.

Dans le scénario client MCP et serveur MCP, il s'agit de "utilisateurs autorisant le client MCP à accéder aux ressources utilisateur sur le serveur MCP". Les "ressources utilisateur sur le serveur MCP" se réfèrent actuellement principalement aux outils fournis par le serveur MCP ou aux ressources fournies par les services en backend du serveur MCP.

Pour mettre en œuvre le processus d'authentification OAuth 2.1, le protocole exige qu'un serveur MCP fournisse les interfaces suivantes pour collaborer avec le client MCP afin de compléter le processus d'authentification OAuth 2.1 :

• /.well-known/oauth-authorization-server : Métadonnées du serveur OAuth
• /authorize : Point de terminaison d'autorisation, utilisé pour les requêtes d'autorisation
• /token : Point de terminaison de jeton, utilisé pour l'échange et le rafraîchissement du jeton
• /register : Point de terminaison d'enregistrement de client, utilisé pour l'enregistrement dynamique des clients

Le processus d'authentification est le suivant :

La Spec spécifie aussi comment le serveur MCP soutient l'autorisation déléguée par des serveurs d'autorisation tiers.

Le flux d'exemple dans la Spec est le suivant (tiré du contenu de la Spec) :

Dans ce scénario, bien que le serveur MCP délègue l'autorisation à un serveur d'autorisation tiers, le serveur MCP agit toujours en tant que serveur d'autorisation pour le client MCP. Cela est dû au fait que le serveur MCP doit émettre son propre jeton d'accès au client MCP.

À mon avis, ce scénario semble plus adapté pour gérer les situations où le serveur MCP proxy le client MCP (utilisateur) pour accéder à des ressources tierces (telles que des dépôts Github), plutôt que le serveur MCP proxyant le client MCP (utilisateur) pour accéder à ses propres ressources.

En résumé, selon le protocole, le serveur MCP joue à la fois les rôles de serveur d'autorisation et de serveur de ressources dans OAuth.

Ensuite, discutons des responsabilités du serveur MCP en tant que serveur d'autorisation et serveur de ressources.

Serveur MCP en tant que service d'autorisation#

Lorsque le serveur MCP agit en tant que serveur d'autorisation, cela signifie que l'utilisateur final du client MCP a sa propre identité sur le serveur MCP. Le serveur MCP est responsable de l'authentification de cet utilisateur final et de l'émission d'un jeton d'accès à cet utilisateur final pour accéder aux ressources du serveur MCP.

Les interfaces liées à l'autorisation requises par la spec d'autorisation MCP mentionnées ci-dessus signifient que le serveur MCP doit fournir une implémentation du serveur d'autorisation.

Cependant, mettre en œuvre la fonctionnalité de serveur d'autorisation sur le serveur MCP est un défi important pour les développeurs. D'une part, la plupart des développeurs peuvent ne pas être familiers avec les concepts liés à OAuth. D'autre part, de nombreux détails doivent être pris en compte lors de la mise en œuvre du serveur d'autorisation. Si un développeur ne provient pas d'un domaine connexe, il peut introduire des problèmes tels que des problèmes de sécurité lors de la mise en œuvre.

Cependant, le protocole lui-même ne limite pas le serveur MCP à mettre en œuvre uniquement la fonctionnalité de serveur d'autorisation lui-même. Les développeurs peuvent totalement rediriger ou mettre en proxy ces points de terminaison liés à l'autorisation vers d'autres serveurs d'autorisation. Cela n'est pas différent pour le client MCP que le serveur MCP implémentant la fonctionnalité de serveur d'autorisation lui-même.

Vous vous demandez peut-être si cette approche devrait utiliser la méthode de délégation d'autorisation par un tiers mentionnée ci-dessus ?

De mon point de vue, cela dépend principalement de savoir si les utilisateurs du service d'autorisation tiers sur lequel vous vous fiez sont les mêmes que les utilisateurs finaux du serveur MCP. Cela signifie que le jeton d'accès émis par le service d'autorisation tiers vous sera directement consommé par votre serveur MCP.

• Si oui, vous pouvez totalement rediriger les interfaces liées à l'authentification de votre serveur MCP vers les services d'autorisation tiers.

• Si non, vous devriez utiliser l'approche d'autorisation déléguée par un tiers spécifiée dans la Spec. Vous devez maintenir une relation de mappage entre les jetons d'accès émis par le serveur MCP lui-même et les jetons d'accès émis par les services d'autorisation tiers dans le serveur MCP.

Je pense que l'approche d'autorisation déléguée par un tiers spécifiée dans le protocole est quelque peu vague dans les scénarios d'application pratique. Le protocole semble laisser les tiers aider le serveur MCP à compléter le processus d'autorisation, mais exige toujours que le serveur MCP émette son propre jeton d'accès. Cela signifie en réalité que le serveur MCP supporte toujours la responsabilité de l'émission de jetons d'accès en tant que serveur d'autorisation, ce qui n'est pas plus pratique pour les développeurs. Je pense que c'est probablement parce que les auteurs du protocole ont considéré que renvoyer directement les jetons d'accès tiers au client MCP entraînerait certains problèmes de sécurité (tels que la fuite/abus, etc.).

De mon expérience, le scénario le plus adapté pour l'autorisation déléguée par un tiers spécifiée dans le protocole devrait être le scénario de "utilisateurs autorisant le serveur MCP à accéder à des ressources tierces". Par exemple, un serveur MCP doit accéder à un dépôt Github d'un utilisateur et déployer le code du dépôt sur une plateforme de déploiement de code. Dans ce cas, l'utilisateur doit autoriser le serveur MCP à accéder à leur dépôt Github et à accéder à la plateforme de déploiement de code.

Dans ce scénario, le serveur MCP est un serveur d'autorisation pour le client MCP, car les utilisateurs finaux ont leur propre identité sur le serveur MCP. Le serveur MCP est un client tiers pour les ressources tierces (dans ce cas, Github). Il doit obtenir l'autorisation de l'utilisateur pour accéder aux ressources utilisateur sur Github. Entre le client MCP et le serveur MCP, et entre le serveur MCP et les ressources tierces, les identités des utilisateurs sont séparées. Cela rend significatif de maintenir une relation de mappage entre les jetons d'accès émis par le serveur MCP lui-même et les jetons d'accès émis par les services d'autorisation tiers dans le serveur MCP.

Ainsi, le protocole d'autorisation déléguée par un tiers dans le protocole devrait résoudre le problème de "comment les utilisateurs autorisent le serveur MCP à accéder aux ressources utilisateur sur des serveurs de ressources tiers".

Serveur MCP en tant que serveur de ressources#

Lorsque le serveur MCP agit en tant que serveur de ressources, le serveur MCP doit vérifier si la demande du client MCP contient un jeton d'accès valide. Le serveur MCP décidera s'il permet ou non au client MCP d'accéder aux ressources spécifiques en fonction de la portée du jeton d'accès.

D'après la définition de MCP, la ressource fournie par le serveur MCP devrait être des outils pour le client MCP à utiliser. Dans ce scénario, le serveur MCP doit uniquement décider s'il fournit aux utilisateurs l'accès à certains outils.

Mais dans des scénarios réels, ces outils fournis par le serveur MCP doivent également interagir avec le serveur de ressources du fournisseur de services du serveur MCP lui-même. À ce moment-là, le jeton d'accès obtenu par le serveur MCP à partir de la demande du client doit être utilisé pour accéder à son propre serveur de ressources. Dans la plupart des cas, le serveur MCP et le serveur de ressources derrière les outils sont le même développeur. Le serveur MCP est juste une interface fournie par ses propres ressources backend pour que le client MCP les utilise. À ce moment-là, le serveur MCP peut partager le même jeton d'accès émis par un serveur d'autorisation avec les ressources backend.

Dans ce cas, plutôt que de dire que le serveur MCP est un serveur de ressources, fournissant des outils et des ressources de ses propres services, il est préférable de dire que le serveur de ressources existant devient un serveur MCP en fournissant des outils pour que le client MCP les appelle.

Inclure les ressources fournies par son propre serveur de ressources dans les ressources fournies par le serveur MCP est plus une considération à partir des scénarios réels. Mais personnellement, je préfère toujours que les ressources fournies par le serveur MCP se limitent aux outils utilisés par le client MCP et que les ressources dont les outils dépendent devraient être des ressources obtenues par le serveur MCP à partir d'autres serveurs de ressources (y compris le premier et le tiers). De cette façon, tous les scénarios réels peuvent être couverts.

Comment fonctionne l'autorisation MCP#

Après avoir compris les responsabilités du serveur MCP en tant que serveur d'autorisation et serveur de ressources, nous pouvons savoir comment fonctionne spécifiquement l'autorisation MCP :

Enregistrement dynamique des clients#

La Spec définit également comment le serveur d'autorisation identifie les clients. OAuth 2.1 fournit le protocole d'enregistrement dynamique des clients, permettant au client MCP d'obtenir automatiquement l'ID du client OAuth sans intervention manuelle de l'utilisateur.

Selon la Spec, le serveur MCP doit prendre en charge le protocole d'enregistrement dynamique des clients d'OAuth 2.0. De cette façon, le client MCP peut s'enregistrer automatiquement auprès de nouveaux serveurs pour obtenir l'ID du client OAuth. Cette approche est recommandée dans les scénarios MCP principalement parce que :

• Le client MCP ne peut pas connaître tous les serveurs possibles à l'avance
• L'enregistrement manuel causerait des problèmes pour les utilisateurs
• Cela rend la connexion avec de nouveaux serveurs transparente
• Les serveurs peuvent mettre en œuvre leurs propres politiques d'enregistrement

Cependant, d'un point de vue pratique, j'ai quelques réflexions sur l'application de l'enregistrement dynamique des clients dans les scénarios MCP :

• Dans les pratiques de service OAuth pratique, le client correspond généralement à un App métier spécifique. La création dynamique d'un client peut ne pas être propice à la gestion efficace des ressources liées (utilisateurs, App, etc.) dans les services OAuth. Les fournisseurs de services OAuth souhaitent généralement avoir un contrôle clair sur les clients connectés, plutôt que de laisser n'importe quel client s'enregistrer librement comme un client.
• De nombreux services OAuth ne recommandent ou n'autorisent pas les utilisateurs à créer dynamiquement des clients, car cela pourrait conduire à un abus du service. La plupart des fournisseurs de services OAuth matures (tels que GitHub, Google, etc.) exigent que les développeurs enregistrent manuellement les clients via leur console développeur, et peuvent également nécessiter de fournir des informations détaillées sur l'application, l'URL de rappel, etc.
• Enregistrer manuellement un client OAuth est en fait un travail unique pendant le développement, pas quelque chose que chaque utilisateur final doit faire. Cela ne causera pas un grand fardeau aux développeurs.
• Pour le client public (comme les applications natives, les applications à une seule page, etc.), nous avons des méthodes plus sûres pour mettre en œuvre le flux OAuth sans enregistrement dynamique. L'ID client combiné avec PKCE (Proof Key for Code Exchange) peut fournir un flux OAuth suffisamment sécurisé pour un client public sans créer dynamiquement un client.
• Bien que le protocole indique que l'utilisation de l'enregistrement dynamique des clients peut éviter aux clients de devoir connaître l'ID client à l'avance, en fait, le client MCP doit toujours connaître l'adresse du serveur MCP distant à l'avance. Si tel est le cas, préciser l'ID client tout en indiquant l'adresse du serveur MCP distant n'apportera pas beaucoup de tracas en plus. Ou, nous pouvons également créer une convention pour que le client MCP demande l'ID client au serveur MCP, ce qui n'est pas une tâche difficile.

Bien que l'enregistrement dynamique des clients offre en théorie une flexibilité pour l'écosystème MCP, dans l'implémentation pratique, nous devons peut-être considérer si nous avons vraiment besoin de ce mécanisme d'enregistrement dynamique. Pour la plupart des fournisseurs de services, créer et gérer manuellement un client OAuth peut être une méthode plus contrôlable et plus sûre.

Résumé#

Cet article analyse en profondeur la philosophie de conception et les défis de mise en œuvre de la spec d'autorisation MCP. En tant que cadre d'autorisation basé sur OAuth 2.1, cette spécification vise à résoudre le problème clé de la manière dont le serveur MCP distant accède aux ressources utilisateur pour le compte des utilisateurs.

Grâce à une discussion détaillée sur les doubles rôles du serveur MCP en tant que serveur d'autorisation et serveur de ressources, ainsi que sur les avantages et les inconvénients des mécanismes tels que l'enregistrement dynamique des clients et la délégation d'autorisation par des tiers, cet article fournit des réflexions et des suggestions issues de l'expérience personnelle en matière de mise en œuvre d'authentificateurs.

Il est à noter que la spécification d'autorisation MCP est encore en évolution. En tant que membre de l'équipe Logto, nous continuerons à prêter attention aux derniers développements de cette spécification et à optimiser en continu nos solutions de mise en œuvre dans la pratique pour contribuer à l'interaction sécurisée entre les modèles d'IA et les services externes.