Mit welcher Identität ein MCP-Tool auf ein Fachsystem zugreifen sollte

Bis zu vier Identitäten in einem einzigen Tool-Aufruf

An einem entfernten MCP-Aufruf sind die Person am Assistenten, die Client-Anwendung, die für sie handelt, der MCP-Server und das Fachsystem dahinter beteiligt. Die aktuelle, optionale MCP-Autorisierungsspezifikation regelt einen Abschnitt davon. Bei einem über HTTP geschützten Server holt der Client ein Token für den MCP-Server, wobei er den Server im resource-Parameter benennt, und der Server muss prüfen, dass das Token für ihn ausgestellt wurde. Für stdio sieht die Spezifikation stattdessen Zugangsdaten aus der Umgebung vor, meist also Zugangsdaten, die die Person hinterlegt hat, die den Server gestartet hat.

Der Abschnitt vom MCP-Server zum Fachsystem liegt außerhalb dessen, was MCP standardisiert. Die Spezifikation erlaubt dem Server, gegenüber Upstream-APIs als OAuth-Client mit einem eigenen Token des dortigen Autorisierungsservers aufzutreten, und verbietet, das empfangene Token durchzureichen. Aus dem MCP-Ablauf allein erhält der Server keine Rechte des Nutzers im Fachsystem.

Drei Optionen für den Aufruf des Fachsystems

1. 1

   Delegierte Zustimmung im Fachsystem

   Der Nutzer autorisiert den MCP-Server über den eigenen OAuth-Ablauf des Fachsystems. Dessen Regeln entscheiden über die Sichtbarkeit, und sein Audit-Log nennt die Person. Der Server muss je Nutzer ein Token speichern und Ablauf sowie Widerruf behandeln.

2. 2

   Token Exchange

   Ein Security Token Service stellt nach RFC 8693 ein neues Token für das Fachsystem als Empfänger aus. Der RFC unterscheidet Impersonation, bei der der Server vom Nutzer nicht mehr zu unterscheiden ist, von Delegation, bei der der Server seine eigene Identität behält und für den Nutzer handelt. Delegation hält beide für Prüfer sichtbar, sofern das Fachsystem sie auswertet.

3. 3

   Service-Identität

   Der Server nutzt eigene Zugangsdaten. Das passt zu geplanten Jobs und zu Daten, die nicht nutzerbezogen sind. Das Fachsystem sieht nur den Dienst, deshalb setzt der Server nutzerbezogene Regeln selbst durch und protokolliert die authentifizierte Dienst- oder Workflow-Identität sowie die Person, die die Aktion ausgelöst oder freigegeben hat, sofern es eine gibt. Wer für jeden Workflow verantwortlich ist, wird gesondert festgehalten.

Eine durchgespielte Entscheidung für drei hypothetische Tools

So könnte die Wahl für einen Assistenten in Personal und Einkauf ausfallen. Systeme und Tools sind für das Beispiel erfunden.

• get_leave_balance liest die Urlaubsdaten eines Mitarbeiters. Das HR-System regelt bereits, wer wessen Daten sieht, also nutzt das Tool das delegierte Token des Anfragenden. Mit einer Service-Identität müsste der Server die Sichtbarkeitsregeln der Personalabteilung nachbauen, und jede Lücke würde Daten anderer Personen offenlegen.
• nightly_supplier_sync aktualisiert Lieferanten-Risikobewertungen aus einem externen Feed. Hinter dem Lauf steht keine Person, also ist eine Service-Identität, die nur diese Felder schreiben darf, die ehrliche Wahl, mit eigenen Zugangsdaten und einem benannten Verantwortlichen.
• create_purchase_request nutzt das delegierte Token des Anfragenden, damit Freigabeketten und Ausgabelimits für die richtige Person gelten. Der Anfragende bestätigt die genaue Bestellanforderung, und der Server oder das Einkaufssystem prüft diese Bestätigung, bevor etwas angelegt wird.

Ein gemischtes Ergebnis ist normal. Entscheiden Sie je Tool und halten Sie die Begründung neben der Tool-Definition fest, wo Reviewer danach suchen.

Token-Grenzen, die vor dem Start geprüft sein sollten

• Der MCP-Server lehnt Tokens für andere Empfänger ab, auch gültige Tokens Ihres eigenen Identity Providers, die für eine andere Anwendung gedacht sind
• Aufrufe des Fachsystems verwenden nie das eingehende Token, und jedes Upstream-Token wird für genau diese API mit den engsten Scopes angefordert
• Nutzerbezogene Tokens auf dem Server sind verschlüsselt, nach Nutzer und Aussteller geschlüsselt und werden gelöscht, wenn der Nutzer den Zugriff widerruft oder das Unternehmen verlässt
• Access Tokens sind kurzlebig, und Refresh Tokens für Public Clients werden rotiert, was die Spezifikation von Autorisierungsservern verlangt
• Kein Token und kein Autorisierungscode erscheint in Logs, Traces oder Tool-Ausgaben, denn die Spezifikation stuft auf dem Server zwischengespeicherte oder protokollierte Tokens als Diebstahlrisiko ein
• Die Deaktivierung eines Nutzers im Identity Provider beendet seinen Zugriff über alle Tools innerhalb einer Zeit, die Sie gemessen haben

Wo die unternehmensgesteuerte Autorisierung passt

Viele Organisationen wollen, dass der Identity Provider und nicht jeder einzelne Mitarbeiter entscheidet, welche MCP-Server genutzt werden dürfen. Die offizielle Erweiterung Enterprise-Managed Authorization leistet das: Der Client holt beim Identity Provider des Unternehmens einen Identity Assertion Grant, der Richtlinien wie Gruppenzugehörigkeit auswertet, und tauscht ihn beim Autorisierungsserver des MCP-Servers gegen ein Access Token. Der Zugang zu MCP-Servern lässt sich dann zentral gewähren und entziehen.

Zwei Grenzen sind wichtig. Die Erweiterung regelt den Zugang zum MCP-Server, nicht die Rechte in den Systemen dahinter, die Entscheidung für den Aufruf des Fachsystems bleibt also bestehen. Außerdem braucht sie ausdrückliche Unterstützung im Client und ist nie standardmäßig aktiv. Das MCP-Projekt führt eine von der Community gepflegte Übersicht zur Client-Unterstützung. Für Verbindungen ganz ohne Nutzer gibt es eine eigene offizielle Erweiterung für den OAuth Client Credentials Grant, die signierte JWT-Assertions gegenüber langlebigen Client Secrets empfiehlt.

Ein sinnvoller nächster Schritt ist eine einseitige Identitätsübersicht für den ersten geplanten Server: jedes Tool, die Identität, die es im Fachsystem nutzt, die Begründung und wer sie entziehen kann.

MCP-Server-Entwicklung