In der heutigen digitalen Landschaft gewinnt die sichere Verwaltung von Zugriffsrechten immer mehr an Bedeutung, insbesondere wenn Unternehmen moderne Protokolle und Technologien implementieren, um ihre Systeme zu skalieren und gleichzeitig die Datenschutz- und Sicherheitsanforderungen einzuhalten. Das Model Context Protocol, kurz MCP, hat in der AI-Ökosphäre große Aufmerksamkeit erlangt. Doch während immer mehr Unternehmen MCP einführen möchten, um von dessen innovativen Funktionen zu profitieren, stoßen sie auf erhebliche Schwierigkeiten im Bereich der Authorisierung. Die MCP-Authorisierungsspezifikation, die kürzlich aktualisiert wurde und nun OAuth 2. 1 als Grundlage verwendet, entpuppt sich für viele Enterprise-Organisationen als echte Herausforderung. Die dabei auftretenden Hürden erschweren eine nahtlose Integration in bestehende Sicherheitsinfrastrukturen und gefährden die Skalierbarkeit von Anwendungen erheblich.
Diese Problematik wirft grundsätzliche Fragen zur Architektur der MCP-Server und der Trennung von Authorisierungs- und Ressourcenverwaltung auf. Zu Beginn ist es wichtig, die ursprüngliche Motivation für die Einführung einer Authorisierungsschicht im MCP zu verstehen. MCP-Server und -Clients kommunizieren derzeit überwiegend über das sogenannte stdio-Transportprotokoll, was in vielen Anwendungsfällen eine 1:1-Deployment-Architektur bedingt. Während dies für erste Experimentierphasen und kleinere Umgebungen ausreichend sein mag, bestehen in größeren, verteilten Unternehmensinfrastrukturen klare Anforderungen an die Möglichkeit, MCP-Server remote zu betreiben und dennoch sicherzustellen, dass Zugriffskontrollen strikt eingehalten werden. Genau hier setzt die jüngste Revision der MCP-Authorisierungsspezifikation an, die OAuth 2. 1 als Standard für die sichere Delegation von Zugriffsrechten vorschreibt.
Doch die Umsetzung dieses Standards bringt eine Reihe komplexer Schwierigkeiten mit sich. Ein Kernproblem der Spezifikation liegt in der Verquickung zweier wesentlicher OAuth-Rollen: des Resource Servers und des Authorization Servers. Klassischerweise sind diese beiden Komponenten bei OAuth strikt getrennt. Der Resource Server beherbergt die zu schützenden Daten oder Funktionen, während der Authorization Server für die Ausstellung und Verwaltung von Zugriffstoken zuständig ist. Diese Trennung ermöglicht eine klare Verantwortlichkeit, sowie eine Unabhängigkeit und Skalierbarkeit der jeweiligen Komponenten. Im MCP-Ansatz hingegen wird der MCP-Server dazu verpflichtet, beide Rollen gleichzeitig zu übernehmen. Damit wird er nicht nur zum Verwalter der Ressourcen, sondern auch zum Herausgeber und Verwalter der Tokens – eine Aufgabe, die erhebliche technische und sicherheitsrelevante Herausforderungen mit sich bringt.
Unternehmen setzen beim OAuth-Management überwiegend auf etablierte Identity Provider wie Auth0, Keycloak oder Okta. Diese Anbieter sind darauf spezialisiert, die komplexen Prozesse rund um Token-Ausstellung, Widerruf, Erneuerung und Verwaltung sicher und skalierbar zu gestalten. Wenn MCP-Server diese Rolle jedoch selbst übernehmen müssen, führt dies zu einer starken Verkomplizierung der Implementierung. Ein solcher MCP-Server wird zwangsläufig stateful, da er Token ausstellen und verwalten muss und somit beispielsweise sichere Datenbanken oder Caches benötigt, um den Status von Tokens, deren Ablaufzeiten und Widerrufe zu speichern. Dies erschwert nicht nur das horizontale Skalieren, sondern erhöht auch den Aufwand für Sicherheitsprüfungen und Audits signifikant. Ein weiteres Detail, welches die Spezifikation erschwert, ist die Einführung des OAuth 2. 0 Authorization Server Metadata-Protokolls. Dieses Protokoll verlangt, dass der MCP-Server unter einem bestimmten Pfad (.
well-known/oauth-authorization-server) Metadaten über seine Authorisierungsendpunkte bereitstellt – inklusive Pfaden für Autorisierung, Tokenvergabe und Clientregistrierung. Doch in der etablierten OAuth-Welt ist es unüblich und gegen Best Practices, dass jeder einzelne Resource Server eigene Authorisierungsendpunkte bereitstellen muss. Stattdessen werden diese zentral von einem Identity Provider bereitgestellt, wodurch eine konsistente und wartungsarme Infrastruktur entsteht. Die Forderung, dass jeder MCP-Server eigene Endpunkte anbietet, erzeugt eine Fragmentierung der OAuth-Landschaft und erschwert die Entwicklung und das Management von MCP-Clients erheblich. Client-Anwendungen müssen sich mit einer Vielzahl unterschiedlicher Endpunkte auseinandersetzen, was die Komplexität und Fehleranfälligkeit erhöht.
Ein Versuch, dieses Problem zu umgehen, wäre es, den MCP-Server lediglich als Resource Server zu betreiben und die Authorisierungsfunktionen vollständig an einen externen Identity Provider zu delegieren. Hierbei würde der MCP-Server seine Metadaten daraufhin anpassen, dass die Clients die Endpunkte des externen Authorization Servers nutzen. Obwohl dies näher an der bewährten Architektur von Unternehmensnetzwerken liegt, bringt es andere Herausforderungen mit sich. Laut MCP-Spezifikation müssen MCP-Server in diesem Szenario sicherstellen, dass sie die von Drittanbietern ausgestellten Tokens mit ihren eigenen MCP-spezifischen Tokens verknüpfen, die Gültigkeit und den Status dieser Drittanbietertokens verifizieren und das Lifecycle-Management der Tokens eigenständig übernehmen. Dieses sogenannte Token Chaining und Management ist eine zusätzliche Komplexitätsstufe, die viele MCP-Server-Implementationen vor große Probleme stellt.
Zudem erhöht sich der infrastrukturelle Aufwand, denn die Verwaltung und sichere Speicherung der Token erfordern eigene Datenbanken mit hohen Sicherheitsanforderungen. Verzögerungen bei der Token-Validierung oder -Widerruf stellen potentielle Schwachstellen dar, wenn sie nicht ordnungsgemäß gehandhabt werden. All diese Faktoren führen dazu, dass das Ziel, eine einfache, skalierbare und sichere Authorisierung in MCP umzusetzen, durch die Spezifikationsdetails direkt konterkariert wird. Für Unternehmen bedeutet dies, dass sie entweder erhebliche Anpassungen in der MCP-Serverimplementierung vornehmen müssen oder mit potenziell unsicheren, schwer wartbaren Architekturen leben müssen. Die Trägheit der MCP-Spezifikation, welche die beiden OAuth-Rollen vermischt, steht im klaren Gegensatz zu den bewährten Sicherheitspraktiken der Industrie. Es stellt sich daher die Frage, wie Unternehmen diese Diskrepanz in der Praxis überwinden können.
Eine vielversprechende Möglichkeit besteht darin, die Rollen klar zu trennen, auch wenn dies einen Bruch mit der aktuellen MCP-Spezifikation bedeutet. Das bedeutet konkret, dass Unternehmen ihre bestehenden Identity Provider weiterhin für die gesamte Authorisierungslogik nutzen und die MCP-Server lediglich als Resource Server betreiben. Diese MCP-Server prüfen dann ausschließlich die von den IdPs ausgestellten Zugriffstoken und setzen entsprechende Zugriffsrechte anhand von Rollen oder Berechtigungen durch. Optional können API-Gateways zum Einsatz kommen, die vor der MCP-Ressource die Tokenvalidierung übernehmen und die Anfragen mittels sicherer Machine-to-Machine-Identitäten (zum Beispiel über SPIFFE und mTLS) an die MCP-Server weiterleiten. Auf diese Weise bleiben die MCP-Server stateless, leichter skalierbar und einfacher zu warten.
Eine weitere offene Frage in der MCP-Community ist, wie ein MCP-Server einem MCP-Client mitteilen kann, welcher Authorization Server genutzt werden soll, falls eine nicht autorisierte Anfrage erfolgt. Ein vorgeschlagenes Muster sieht vor, dies über den HTTP-Header WWW-Authenticate zu kommunizieren, der neben Fehlermeldungen auch die URL des OAuth-Authorization-Endpunkts sowie weitere Metadaten mitliefert. Diese Lösung bietet eine elegante Möglichkeit, Clients dynamisch über notwendige Authentifizierungsdetails zu informieren, ohne dass diese bei jeder neuen Verbindung manuell konfiguriert werden müssen. Es ist erfreulich, dass sich in der Community ein Dialog zu diesen Herausforderungen entwickelt hat. Die gewonnenen Erkenntnisse fließen in Vorschläge zur Überarbeitung der MCP-Authorisierungsspezifikation ein, um sie besser an die Anforderungen von Unternehmen anzupassen.
Indem sie die bewährten Prinzipien der OAuth-Architektur stärker respektiert und die Komplexität von MCP-Servern reduziert, kann die Akzeptanz und Sicherheit von MCP in der Enterprise-Welt maßgeblich verbessert werden. Zusammenfassend lässt sich sagen, dass die aktuelle MCP-Authorisierungsspezifikation für Unternehmen eine komplexe und schwer zu implementierende Herausforderung darstellt. Die mangelnde Trennung zwischen Authorization Server und Resource Server widerspricht bewährten Sicherheitsprinzipien und erschwert Skalierbarkeit und Wartbarkeit von MCP-Servern. Unternehmen sollten daher bestrebt sein, bestehende Identity- und Access-Management-Lösungen bestmöglich zu integrieren, um stabile, sichere und skalierbare Umgebungen zu schaffen.
Die Zukunft der MCP-Authorisierung wird maßgeblich davon abhängen, wie flexibel die Spezifikation auf diese Anforderungen reagiert und wie die Community gemeinsam praktikable Lösungen entwickelt, die sowohl Sicherheit als auch Usability gewährleisten.
