Tiefgehende Überprüfung der MCP-Autorisierungsspezifikation (Ausgabe vom 26.03.2025)

MCP (Model Context Protocol) ist ein offener Standard, der es KI-Modellen ermöglicht, mit externen Tools und Diensten zu interagieren. Es wird in der Industrie weithin angenommen. Da MCP HTTP-basierte Transportmethoden unterstützt, wird der Remote-MCP-Server eine zunehmend wichtige Rolle im MCP-Ökosystem spielen.

Im Gegensatz zum lokalen MCP-Server, der es jedem Benutzer ermöglicht, seine eigene Serverinstanz auszuführen, erfordert der Remote-MCP-Server, dass alle Benutzer denselben MCP-Serverdienst teilen. Dies wirft das Kernproblem auf, das die MCP-Autorisierungsspezifikation zu lösen versucht: wie man es dem MCP-Server erlaubt, im Namen des Nutzers auf Benutzerressourcen zuzugreifen.

Dieser Artikel wird die MCP-Autorisierungsspezifikation eingehend analysieren. Er wird Ihnen helfen, die Designprinzipien der MCP-Autorisierungsspezifikation zu verstehen und einige Richtungen für die Implementierung der MCP-Autorisierung aufzeigen. Da sich diese Spezifikation noch entwickelt, werde ich einige Gedanken basierend auf meinen persönlichen Erfahrungen bei der Implementierung des Authenticators teilen, einschließlich:

• Vorteile und Einschränkungen von OAuth 2.1 als Autorisierungs-Framework
• Herausforderungen der Doppelrollen des MCP-Servers als Autorisierungs- und Ressourcenserver
• Praktische Komplexität der Implementierung eines vollständigen Autorisierungsservers
• Analyse geeigneter Szenarien für delegierte Drittanbieterautorisierung
• Praktische Kompromisse bei der dynamischen Client-Registrierung
• Wichtigkeit einer klaren Definition der Ressourcen-Grenzen des MCP-Servers

Überblick über die MCP-Autorisierungsspezifikation#

Die MCP-Autorisierungsspezifikation definiert den Authentifizierungsprozess zwischen dem MCP-Server (remote) und dem MCP-Client.

Ich denke, die Basis dieser Spezifikation auf OAuth 2.1 ist eine sehr vernünftige Wahl. OAuth als Autorisierungsprotokoll-Framework löst das Problem, wie Benutzer Drittanbieteranwendungen autorisieren können, im Namen des Benutzers auf Benutzerressourcen zuzugreifen. Wenn Sie nicht mit OAuth vertraut sind, können Sie AuthWiki-OAuth für weitere Informationen besuchen.

Im Szenario von MCP-Client und MCP-Server geht es darum, "Nutzer ermächtigen MCP-Client, auf Benutzerressourcen auf dem MCP-Server zuzugreifen". Die "Benutzerressourcen auf dem MCP-Server" beziehen sich derzeit hauptsächlich auf vom MCP-Server bereitgestellte Tools oder die vom Backend-Dienste des MCP-Servers bereitgestellten Ressourcen.

Um den OAuth 2.1-Authentifizierungsprozess zu implementieren, erfordert das Protokoll, dass ein MCP-Server die folgenden Schnittstellen bereitstellt, um mit dem MCP-Client zusammenzuarbeiten, um den OAuth 2.1-Authentifizierungsprozess abzuschließen:

• /.well-known/oauth-authorization-server: OAuth-Server-Metadaten
• /authorize: Autorisierungsendpunkt, verwendet für Autorisierungsanfragen
• /token: Token-Endpunkt, verwendet für Token-Austausch und -Erneuerung
• /register: Client-Registrierungsendpunkt, verwendet für die dynamische Client-Registrierung

Der Authentifizierungsprozess sieht wie folgt aus:

Die Spezifikation legt auch fest, wie der MCP-Server delegierte Autorisierung durch Drittanbieterautorisierungsserver unterstützt.

Der Beispielablauf in der Spezifikation ist wie folgt (aus dem Spezifikationsinhalt):

In diesem Szenario, obwohl der MCP-Server die Autorisierung an einen Drittanbieterautorisierungsserver delegiert, fungiert der MCP-Server weiterhin als Autorisierungsserver für den MCP-Client. Dies liegt daran, dass der MCP-Server sein eigenes Zugriffstoken an den MCP-Client ausstellen muss.

Meiner Meinung nach scheint dieses Szenario besser geeignet zu sein, Situationen zu behandeln, in denen der MCP-Server den MCP-Client (Benutzer) proxyiert, um auf Drittanbieterressourcen zuzugreifen (z. B. Github-Repos), anstatt den MCP-Server, der den MCP-Client (Benutzer) proxyiert, um auf eigene Ressourcen des MCP-Servers zuzugreifen.

Zusammengefasst spielt der MCP-Server laut Protokoll sowohl die Rolle des Autorisierungsservers als auch des Ressourcenservers in OAuth.

Als nächstes diskutieren wir die Verantwortlichkeiten des MCP-Servers als Autorisierungsserver und Ressourcenserver.

MCP-Server als Autorisierungsdienst#

Wenn der MCP-Server als Autorisierungsserver fungiert, bedeutet dies, dass der Endbenutzer des MCP-Clients seine eigene Identität auf dem MCP-Server hat. Der MCP-Server ist dafür verantwortlich, diesen Endbenutzer zu authentifizieren und diesem Endbenutzer ein Zugriffstoken für den Zugriff auf MCP-Server-Ressourcen auszustellen.

Die oben erwähnten autorisierungsbezogenen Schnittstellen, die von der MCP-Autorisierungsspezifikation gefordert werden, bedeuten, dass der MCP-Server eine Implementierung des Autorisierungsservers bereitstellen muss.

Die Implementierung der Autorisierungsserverfunktionen auf dem MCP-Server ist jedoch eine erhebliche Herausforderung für Entwickler. Einerseits sind die meisten Entwickler möglicherweise nicht mit den Konzepten im Zusammenhang mit OAuth vertraut. Andererseits gibt es viele Details zu berücksichtigen, wenn man einen Autorisierungsserver implementiert. Wenn ein Entwickler nicht aus einem verwandten Bereich stammt, können sie möglicherweise Sicherheitsprobleme während der Implementierung einführen.

Das Protokoll selbst beschränkt den MCP-Server jedoch nicht darauf, nur die Funktionen des Autorisierungsservers selbst zu implementieren. Entwickler können diese autorisierungsbezogenen Endpunkte vollständig zu anderen Autorisierungsservern umleiten oder proxyen. Für den MCP-Client macht dies keinen Unterschied als die Implementierung der Funktionen des Autorisierungsservers durch den MCP-Server.

Sie fragen sich vielleicht, ob dieser Ansatz die oben erwähnte delegierte Drittanbieter-Autorisierungsmethode verwenden sollte?

Meiner Ansicht nach hängt dies hauptsächlich davon ab, ob die Benutzer des Drittanbieter-Autorisierungsdienstes, auf den Sie sich verlassen, dieselben sind wie die Endbenutzer des MCP-Servers. Das bedeutet, dass das Zugriffstoken, das Ihnen vom Drittanbieter-Autorisierungsdienst ausgestellt wird, direkt von Ihrem MCP-Server konsumiert wird.

• Wenn ja, können Sie die auth-bezogenen Schnittstellen in Ihrem MCP-Server vollständig an Drittanbieter-Autorisierungsdienste weiterleiten.

• Wenn nicht, sollten Sie den in der Spezifikation angegebenen Ansatz der delegierten Drittanbieter-Autorisierung verwenden. Sie müssen eine Zuordnungsbeziehung zwischen Zugriffstoken, die vom MCP-Server selbst ausgestellt wurden, und Zugriffstoken, die von Drittanbieter-Autorisierungsdiensten ausgestellt wurden, im MCP-Server beibehalten.

Ich denke, der im Protokoll angegebene Ansatz der delegierten Drittanbieter-Autorisierung ist in praktischen Anwendungsszenarien etwas vage. Das Protokoll scheint Drittanbieter zu lassen, um dem MCP-Server bei der Vervollständigung des Autorisierungsprozesses zu helfen, verlangt aber immer noch, dass der MCP-Server sein eigenes Zugriffstoken ausstellt. Dies bedeutet tatsächlich, dass der MCP-Server weiterhin die Verantwortung für die Ausstellung von Zugriffstoken als Autorisierungsserver trägt, was für Entwickler nicht bequemer ist. Ich denke, es liegt wahrscheinlich daran, dass die Autoren des Protokolls in Betracht gezogen haben, dass die direkte Rückgabe von Drittanbieter-Zugriffstoken an den MCP-Client einige Sicherheitsprobleme mit sich bringen würde (z. B. Lecks/ Missbrauch usw.).

Meiner Erfahrung nach sollte das am besten geeignete Szenario für die im Protokoll angegebene delegierte Drittanbieter-Autorisierung das Szenario "Benutzer, die den MCP-Server autorisieren, um auf Drittanbieter-Ressourcen zuzugreifen" sein. Zum Beispiel muss ein MCP-Server auf das Github-Repo eines Benutzers zugreifen und den Code des Repos auf einer Code-Bereitstellungsplattform bereitstellen. In diesem Fall muss der Benutzer den MCP-Server autorisieren, um auf sein Github-Repo zuzugreifen und um auf die Code-Bereitstellungsplattform zuzugreifen.

In diesem Szenario ist der MCP-Server ein Autorisierungsserver für den MCP-Client, weil Endbenutzer ihre eigene Identität auf dem MCP-Server haben. Der MCP-Server ist ein Drittanbieter-Client für Drittanbieter-Ressourcen (in diesem Fall Github). Er muss die Benutzerautorisierung einholen, um auf Benutzerressourcen auf Github zuzugreifen. Zwischen dem MCP-Client und dem MCP-Server sowie zwischen dem MCP-Server und den Drittanbieter-Ressourcen sind die Benutzeridentitäten getrennt. Das macht es sinnvoll, eine Zuordnungsbeziehung zwischen Zugriffstoken, die vom MCP-Server selbst ausgestellt wurden, und Zugriffstoken, die von Drittanbieter-Autorisierungsdiensten ausgestellt wurden, im MCP-Server beizubehalten.

Das delegierte Drittanbieter-Autorisierungsprotokoll im Protokoll sollte also das Problem "wie Benutzer den MCP-Server autorisieren, um auf Benutzerressourcen auf Drittanbieter-Ressourcenservern zuzugreifen" lösen.

MCP-Server als Ressourcenserver#

Wenn der MCP-Server als Ressourcenserver fungiert, muss der MCP-Server überprüfen, ob die Anfrage des MCP-Clients ein gültiges Zugriffstoken trägt. Der MCP-Server wird entscheiden, ob er dem MCP-Client den Zugriff auf bestimmte Ressourcen basieren auf dem Umfang des Zugriffstokens erlaubt.

Gemäß der Definition von MCP sollte die vom MCP-Server bereitgestellte Ressource Werkzeuge sein, die vom MCP-Client verwendet werden. In diesem Szenario muss der MCP-Server nur entscheiden, ob er Benutzern den Zugang zu bestimmten Werkzeugen bietet.

Aber in realen Szenarien müssen diese vom MCP-Server bereitgestellten Werkzeuge auch mit dem Ressourcenserver des MCP-Server-Dienstanbieters selbst interagieren. Zu diesem Zeitpunkt muss das Zugriffstoken, das der MCP-Server aus der Clientanforderung erhält, verwendet werden, um auf seinen eigenen Ressourcenserver zuzugreifen. In den meisten Fällen sind der MCP-Server und der Ressourcenserver hinter den Werkzeugen derselbe Entwickler. Der MCP-Server ist nur eine Schnittstelle, die von eigenen Backend-Ressourcen für den Gebrauch durch den MCP-Client bereitgestellt wird. Zu diesem Zeitpunkt können der MCP-Server und der Ressourcenserver dasselbe Zugriffstoken von einem Autorisierungsserver teilen.

In diesem Fall ist es besser zu sagen, dass anstatt dass der MCP-Server ein Ressourcenserver ist, um Werkzeuge und Ressourcen des eigenen Dienstes bereitzustellen, der vorhandene Ressourcenserver zu einem MCP-Server wird, indem Werkzeuge für den Anruf durch den MCP-Client bereitgestellt werden.

Bieten von Ressourcen, die vom eigenen Ressourcenserver bereitgestellt werden, in die vom MCP-Server bereitgestellten Ressourcen ist mehr aus der Berücksichtigung realer Szenarien. Aber ich persönlich bevorzuge immer noch, dass die vom MCP-Server bereitgestellten Ressourcen nur Werkzeuge sind, die vom MCP-Client verwendet werden, und die Ressourcen, von denen die Werkzeuge abhängig sind, sollten Ressourcen sein, die der MCP-Server von anderen Ressourcenservern (einschließlich erstens und dritten Parteien) erhalten hat. Auf diese Weise können alle realen Szenarien abgedeckt werden.

Wie MCP-Autorisierung funktioniert#

Nach dem Verständnis der Verantwortlichkeiten des MCP-Servers als Autorisierungsserver und Ressourcenserver können wir wissen, wie MCP-Autorisierung speziell funktioniert:

Dynamische Client-Registrierung#

Die Spezifikation definiert auch, wie der Autorisierungsserver Clients identifiziert. OAuth 2.1 bietet ein Protokoll zur dynamischen Client-Registrierung, das es dem MCP-Client ermöglicht, automatisch eine OAuth-Client-ID zu erhalten, ohne dass manuelles Benutzereingreifen erforderlich ist.

Gemäß der Spezifikation sollte der MCP-Server das Protokoll zur dynamischen Client-Registrierung von OAuth 2.0 unterstützen. Auf diese Weise kann sich der MCP-Client automatisch bei neuen Servern registrieren, um eine OAuth-Client-ID zu erhalten. Dieser Ansatz wird in MCP-Szenarien hauptsächlich deshalb empfohlen, weil:

• Der MCP-Client nicht alle möglichen Server im Voraus kennen kann
• Manuelle Registrierung würde den Benutzern Probleme bereiten
• Es macht die Verbindung mit neuen Servern nahtlos
• Server können ihre eigenen Registrierungsrichtlinien umsetzen

Jedoch habe ich aus praktischer Perspektive einige Gedanken zur Anwendung der dynamischen Client-Registrierung in MCP-Szenarien:

• In der praktischen OAuth-Service-Praxis ist der Client normalerweise direkt einem bestimmten Business-App zugeordnet. Dynamische Erstellung von Clients könnte nicht förderlich sein, um verbundene Ressourcen (Benutzer, App, etc.) in OAuth-Diensten effektiv zu verwalten. OAuth-Anbieter möchten normalerweise klare Kontrolle über verbundene Clients haben, anstatt dass jeder Client sich einfach als Client registrieren kann.
• Viele OAuth-Dienste empfehlen oder erlauben es nicht, dass Benutzer dynamisch Clients erstellen, da dies möglicherweise zu Missbrauch des Dienstes führen könnte. Die meisten ausgereiften OAuth-Dienstanbieter (wie GitHub, Google, etc.) verlangen, dass Entwickler Clients manuell über ihre Entwicklerkonsole registrieren und möglicherweise auch detaillierte Informationen über die Anwendung, die Callback-URL, etc. bereitstellen müssen.
• Die manuelle Registrierung von OAuth-Clients ist eigentlich eine einmalige Arbeit während der Entwicklung, die nicht jeder Endbenutzer tun muss. Es wird keine große Belastung für die Entwickler darstellen.
• Für öffentliche Clients (wie native Anwendungen, Single-Page-Anwendungen, etc.) haben wir sicherere Wege, um OAuth-Flows ohne dynamische Registrierung umzusetzen. Client-ID in Kombination mit PKCE (Proof Key for Code Exchange) kann einen ausreichend sicheren OAuth-Flow für öffentliche Clients ohne dynamische Client-Erstellung bieten.
• Obwohl das Protokoll darauf hinweist, dass die Verwendung der dynamischen Client-Registrierung verhindern kann, dass Clients die Client-ID im Voraus kennen müssen, benötigt der MCP-Client tatsächlich immer die Adresse des Remote-MCP-Servers im Voraus. Wenn dies der Fall ist, das Angeben der Client-ID beim Übergeben der Remote-MCP-Server-Adresse wird nicht viel zusätzlichen Aufwand bringen. Oder, wir könnten auch eine Konvention für den MCP-Client schaffen, um die Client-ID vom MCP-Server zu erfragen, was keine schwierige Aufgabe ist.

Obwohl die dynamische Client-Registrierung Flexibilität für das MCP-Ökosystem in der Theorie bietet, müssen wir bei der praktischen Implementierung möglicherweise berücksichtigen, ob wir diesen dynamischen Registrierungsmechanismus wirklich brauchen. Für die meisten Dienstanbieter könnte die manuelle Erstellung und Verwaltung von OAuth-Clients eine kontrollierbare und sicherere Methode sein.

Zusammenfassung#

Dieser Artikel analysiert tiefgründig die Designphilosophie und Implementierungsherausforderungen der MCP-Autorisierungsspezifikation. Als Autorisierungsframework basierend auf OAuth 2.1 zielt diese Spezifikation darauf ab, das wesentliche Problem zu lösen, wie Remote-MCP-Server im Auftrag der Benutzer auf Benutzerressourcen zugreifen.

Durch detaillierte Diskussion der Doppelrollen des MCP-Servers als Autorisierungs- und Ressourcenserver sowie die Vor- und Nachteile von Mechanismen wie dynamische Client-Registrierung und delegierte Drittanbieter-Autorisierung bietet dieser Artikel Einsichten und Vorschläge aus persönlicher Erfahrung bei der Implementierung des Authenticators.

Es ist erwähnenswert, dass sich die MCP-Autorisierungsspezifikation noch entwickelt. Als Mitglied des Logto-Teams werden wir die neuesten Entwicklungen dieser Spezifikation weiterhin verfolgen und unsere Implementierungslösungen in der Praxis kontinuierlich optimieren, um zur sicheren Interaktion zwischen KI-Modellen und externen Diensten beizutragen.