MCP-Authentifizierung und -Autorisierung: Die wichtigsten Unterschiede erklärt

Wenn ein AI-Agent eine Verbindung zu einem MCP-Server herstellt, muss der Agent seine Identität überprüfen (MCP-Authentifizierung) und die Funktionen definieren, die er ausführen darf, sobald ihm der Zugriff gewährt wurde (MCP-Autorisierung), um die Sicherheit sowohl für den MCP-Client als auch für das System zu gewährleisten. Es ist wichtig, zwischen diesen beiden Arten von Zugriffskontrollprüfungen zu unterscheiden.

Wenn Sicherheitsüberprüfungen falsch oder austauschbar verwendet werden, entstehen Sicherheitslücken, die Benutzer und Administratoren traditioneller Systeme vor Herausforderungen stellen. In MCP-Umgebungen führt das Fehlen definierter Sicherheitsüberprüfungen zu ernsteren Risiken als in herkömmlichen Systemen.

Dieses Handbuch enthält detaillierte Beschreibungen der MCP-Authentifizierung und -Autorisierung, ihrer Funktionsweise innerhalb des Modellkontext-Protokoll-Ökosystems und der Voraussetzungen für die Implementierung dieser Konzepte für eine erfolgreiche Unternehmensumgebung in einer Live-Produktionsumgebung.

Was ist MCP-Authentifizierung?

Die MCP-Authentifizierung ist der erste Überprüfungspunkt zwischen einem MCP-Client und einem MCP-Server. Bevor ein Befehl über Tools ausgeführt wird, muss sich der Client identifizieren und authentifizieren, um Vertrauen aufzubauen. Für die Authentifizierung bei Remote-MCP-Servern (HTTP/HTTPS) wird am häufigsten OAuth 2.1 mit PKCE verwendet.

Wenn sich ein Agent erfolgreich bei einem Autorisierungsserver authentifiziert, tauscht der Client Anmeldeinformationen gegen ein OAuth-Token aus, häufig über einen Token-Austausch, der am Metadaten-Endpunkt initiiert wird. Der MCP-Server lässt keine Verbindung zu, es sei denn, der Agent hat ein gültiges OAuth-Token.

Im Gegensatz zu den Standardverbindungsmethoden benötigen lokale MCP-Server, die eine Verbindung über STDIO-Transport herstellen, keinen Agenten zur Authentifizierung. Stattdessen verwenden sie die Vertrauensgrenze des Host-Prozesses, die in grundlegenden Anwendungsfällen häufig über Umgebungsvariablen konfiguriert wird.

Die am häufigsten verwendeten Anmeldeinformationstypen lauten wie folgt:

• OAuth 2.1-Zugriffstoken: Dieser Typ der Anmeldeinformationen ist kurzlebig (in der Regel eine Stunde) und in seinem Umfang begrenzt. Er ist der empfohlene Anmeldeinformationstyp für den sicheren Zugriff in Produktionssystemen.
• API-Schlüssel: Dieser Anmeldeinformationstyp ist einfach zu verwenden, läuft nicht ab und hat keine detaillierte Zugriffskontrolle. Er gilt als riskant, wenn viele Benutzer auf externen Systemen verwaltet werden.
• JWTs: Behauptungen über die Identität von Benutzern wie Benutzer, Rolle und Mandant sind in das JWT eingebettet, obwohl sie aufgrund der Notwendigkeit einer zusätzlichen Autorisierungslogik mit zusätzlicher Komplexität verbunden sind.
  

Seit der Aktualisierung der MCP-Spezifikation vom Juni 2025 werden Server nun als OAuth-Ressourcenserver behandelt und validieren Token, stellen jedoch keine Token an Benutzer aus. Stattdessen wurde die Verantwortung für die Ausgabe von Tokens externen Identitätsanbietern wie Okta, Azure AD und Auth0 übertragen.

Dadurch wird eine zentrale MCP-Authentifizierung geschaffen und SSO, MFA und Überprüfbarkeit auf Identitätsebene in das MCP-Ökosystem integriert, ohne dass benutzerdefinierte Implementierungen erforderlich sind.

Was ist MCP-Autorisierung?

Durch die Authentifizierung wird die Identität des Kunden festgelegt, während die MCP-Autorisierung die Fähigkeiten des Kunden bestimmt.

Die Autorisierung regelt die Zugriffskontrolle auf einer sehr detaillierten Ebene und schränkt ein, welche Tools aufgerufen werden können, auf welche Daten zugegriffen werden darf und unter welchen Bedingungen diese Maßnahmen ergriffen werden können. Die Autorisierung wird fortlaufend und nicht als einmalige Bewertung bei jedem Tool-Aufruf evaluiert.

In MCP-Systemen verwendet die Autorisierung in der Regel einen mehrschichtigen Ansatz. Zu den Autorisierungsebenen in MCP-Systemen gehören:

• Bereichsbasierte Berechtigungen: Bei der Token-Ausgabe definierte Berechtigungen, die die äußeren Grenzen aller möglichen OAuth-Bereiche und ergriffenen Aktionen festlegen.
• Rollenbasierte Zugriffskontrolle (RBAC): Zuordnung von Berechtigungen zu Rollen, um sicherzustellen, dass alle Benutzer und alle KI-Agenten, die auf dieselbe Rolle zugreifen, dieselben Rechte für den Zugriff auf diese Ressourcen haben.
• Steuerelemente auf Ressourcenebene: Beschränkung des sicheren Zugriffs auf bestimmte Datensätze, Tools oder Umgebungen.
• Kontextuelle Richtlinien: Anwenden von Laufzeitbedingungen wie Zeit, Anforderungsmustern oder Risikosignalen auf die oben genannten

Die letzte Autorisierungsebene ist der interessanteste Aspekt des modernen MCP-Autorisierungsrahmens. Einem Token, der autorisiert wurde, die read_file-Methode um 9 Uhr aufzurufen, kann aufgrund einer anderen Richtlinie, die für die ersten beiden Referenzparameter gilt, auch die Möglichkeit verweigert werden, dieselbe Methode um 2 Uhr morgens aufzurufen.

Authentifizierung und Autorisierung in MCP: Die wichtigsten Unterschiede

Authentifizierung und Autorisierung werden zwar manchmal verwechselt, stellen aber im Zusammenhang mit MCP einen zweistufigen Ansatz dar. Die beiden Bereiche bieten unterschiedliche Stufen der Zugriffskontrolle, und die einzelnen Ausfallmodi unterscheiden sich entsprechend.

Wenn die Authentifizierung korrekt ist, aber die korrekte Autorisierung nicht erzwungen wird, wird jeder authentifizierte Client zu einem Superuser.

Die Fehlermodi stehen sich oft gegenüber:

• Eine schwache MCP-Authentifizierung ermöglicht die Durchleitung falscher Identitäten.
• Eine schwache MCP-Autorisierung ermöglicht es korrekten Identitäten, übertriebene Aktionen auszuführen.

MCP-Systeme im Produktionsstil erfordern, dass beide Arten der Steuerung unabhängig voneinander durchgesetzt werden

Wie arbeiten MCP-Authentifizierung und Autorisierung in einem echten MCP-Flow zusammen?

Im Folgenden finden Sie ein aktuelles Beispiel für eine Abfolge von Schritten, die ausgeführt werden, wenn ein Agent einen Remote-MCP-Server kontaktiert. Dies führt entweder zu einem erfolgreichen Toolaufruf oder zu einem Fehler.

Schritt 1: Der Agent versucht, als MCP-Client eine Verbindung zum MCP-Server herzustellen. Der MCP-Server erkennt nicht, dass der Client eine offene Sitzung hat, und gibt daher die Antwort 401 Unauthorized zusammen mit den Metadaten des Autorisierungsservers zurück, die auf den Autorisierungsserver verweisen.

Schritt 2: Der Agent sendet eine Umleitungsanforderung an den Autorisierungsserver (entweder Okta, Azure AD oder Auth0), wo der OAuth-Fluss mit PKCE abgeschlossen wird. Der Benutzer oder Dienst authentifiziert sich und stimmt den angeforderten OAuth-Bereichen zu. Er erhält einen Autorisierungscode.

Schritt 3: Nach Erhalt eines Autorisierungscodes vom Autorisierungsserver verwendet der Agent den Autorisierungscodefluss, um ein Zugriffstoken vom Token-Endpunkt abzurufen. Ein Zugriffstoken bietet dem Agenten temporären sicheren Zugriff. Gleichzeitig wird die Authentizität der Kommunikation bestätigt und der Agent auf die genehmigten OAuth-Bereiche beschränkt, die im Namen der anfordernden Anwendung beansprucht wurden.

Schritt 4: Nach Erhalt eines Zugriffstokens kommuniziert der Agent mit MCP, indem er das Zugriffstoken als Trägertoken in den Autorisierungsheader aufnimmt. Der MCP-Server validiert während der Token-Validierung die Signatur, das Ablaufdatum und die ausstellende Entität des Tokens anhand der öffentlichen Schlüssel des Autorisierungsservers, um die Identität des Agenten zu bestätigen.

Schritt 5: Wenn der Agent den MCP-Server mit dem Bereich tools:read aufruft, prüft der MCP-Server zunächst, ob die Bereiche der Zugriffstoken der angeforderten Aktion entsprechen. Da der Gültigkeitsbereich tools: read keine destruktiven Aktionen zulässt, gibt der MCP-Server einen 403 Forbidden Response Code zurück und protokolliert die Zugriffsverweigerung als Teil des Autorisierungsablaufs.

Schritt 6: Um zu verhindern, dass nicht autorisierte Automatisierungs-Workflows falsch konfigurierte Server erreichen, wird eine Policy Engine oder ein MCP-Gateway vor dem MCP-Server platziert. Die Policy-Engine überprüft, ob jeder Toolaufruf keine Geschwindigkeitsbegrenzungen überschreitet oder gegen kontextbasierte Richtlinien oder bereichsbasierte Regeln verstößt, bevor die Anforderung an die Serverlogik weitergeleitet wird.

Was machen Teams bei der MCP-Authentifizierung und -Autorisierung falsch?

Selbst Teams, die beide Ebenen verwenden, missbrauchen sie oft.

• Behandlung eines gültigen Tokens als pauschale Erlaubnis: Einige Unternehmen verwenden gültige Token für den allgemeinen Zugriff, weshalb Entwickler in der Regel neue Token einrichten, die ihnen Rechte gewähren, die sie nicht haben sollten, und verwenden sie über diese Token, um entweder nur auf Entwicklerebene auf Produktionsdatenbankressourcen zuzugreifen oder indem sie Token-Authentifizierungssicherheit verwenden, um fälschlicherweise Zugriff auf die Datenbankressourcen zu erhalten, als sie ursprünglich so eingerichtet wurden, dass dem Entwickler diese Rechte gewährt wurden.
• Autorisierung für interne MCP-Server übersprungen: Eine Netzwerkgrenze allein garantiert nicht, dass Sie nicht auf sie zugreifen können. Jemand mit internem Zugriff kann auf alle internen Ressourcen auf dem Anwendungsserver für die interne Auftragsbearbeitung zugreifen.
• Statische API-Schlüssel, die ohne einen richtigen Autorisierungsstapel verwendet werden: Statische API-Schlüssel haben möglicherweise keine OAuth-Bereiche, Ablauf- oder Sperrmechanismen. Wenn ein statischer API-Schlüssel in einer Protokolldatei oder einem Repository veröffentlicht wird, besteht die einzige Lösung darin, die Anmeldeinformationen zu rotieren, was bei weitem zu Betriebsunterbrechungen führt.
• Verlassen Sie sich ausschließlich auf OAuth-Bereiche ohne RBAC auf Gateway-Ebene: OAuth-Bereiche definieren, was das Token innerhalb einer Sitzung ausführen kann, während Rollen definieren, was die Person ausführen soll. Wenn RBAC nicht auf Gateway-Ebene durchgesetzt wird, hat eine automatisierte Pipeline denselben Zugriff wie ein menschlicher Techniker.
• Der Zugriff wird nicht erneut bewertet, sobald die Erlaubnis zu Beginn einer Sitzung erteilt wurde: Wenn einem KI-Agenten zu Beginn der Sitzung die Erlaubnis erteilt wird, seine Funktion auszuführen, und wenn sich die Rolle des Agenten während der Sitzung ändert, gelten alle vor dieser Änderung erteilten Berechtigungen für den gesamten Zeitraum weiter. Dies ist ein erhebliches Risiko in Agentensystemen, in denen autonome Agenten über längere Sitzungen hinweg operieren können.

Welche Unternehmensimplementierung der MCP-Authentifizierung und -Autorisierung ist erforderlich?

Es ist für Teams oder einzelne Serverimplementierungen nicht möglich, die MCP-Authentifizierung und MCP-Autorisierung in großem Umfang alleine zu handhaben. Vielmehr sollten sie auf mehreren Servern auf Plattformebene implementiert werden.

Um dies zu erreichen, muss Folgendes berücksichtigt werden:

• Zentrales Identitätsmanagement über einen Identitätsanbieter: Alle MCP-Authentifizierungsanfragen auf MCP-Servern müssen denselben Identitätsanbieter durchlaufen, unabhängig davon, ob es sich um Okta, Azure AD oder Auth0 handelt. Die verteilte Authentifizierungskonfiguration lässt sich nicht skalieren und führt zu einer Fragmentierung der Audit-Trails.
• Durch die Infrastruktur erzwungene kurzlebige Scoped-Token: Alle MCP-Server müssen kurzlebige Zugriffstoken mit definierten OAuth-Bereichen über die Infrastruktur durchsetzen. Das Team kann den Ablauf oder den Umfang der Tokens nicht für jede Bereitstellung korrekt definieren, aber die Infrastruktur wird sie konsistent durchsetzen.
• RBAC nach Server und Rolle mit sofortiger Richtlinien-Weitergabe: Wenn ein Team die Rolle eines Benutzers oder Teammitglieds ändert, muss die Änderung sofort auf alle Server übertragen werden und wirksam werden, ohne auf den nächsten Bereitstellungszyklus warten zu müssen.
• Einzigartige kombinierte Audit-Trails für Zugriffs- und Autorisierungsprotokolle: Sowohl Zugriffsprotokolle als auch MCP-Autorisierungsprotokolle werden von verschiedenen Teams benötigt. Beide Teams benötigen Zugriff auf kombinierte Audit-Trails unter Verwendung einer gemeinsamen Anforderungs-ID für zukünftige Untersuchungen.
• Durchsetzung der Gateway-Zugriffskontrolle getrennt vom Anwendungscode: Wenn die Anwendungsrichtlinie auf dem Server gespeichert ist und der Server falsch bereitgestellt wird, kann die Anwendungsrichtlinie unbemerkt deaktiviert werden. Das MCP-Gateway erzwingt jedoch unabhängig vom Verhalten der Anwendung sowohl die Überprüfung der OAuth-Bereiche als auch die Ratenbegrenzungen.

Wie erzwingt TrueFoundry die MCP-Authentifizierung und -Autorisierung auf Plattformebene?

TrueFoundry betrachtet MCP-Authentifizierung und Autorisierung als grundlegende Konzepte seiner Plattform, nicht als Aufgaben, die von einzelnen Anwendungen ausgeführt werden müssen.

• sofort einsatzbereite IdP-Integration für Unternehmen: TrueFoundry ermöglicht es Unternehmen, ihren Unternehmensidentitätsanbieter mithilfe von Okta, Azure AD oder einem anderen OAuth-Autorisierungsserver, der OAuth 2.0 unterstützt, zu verbinden. Authentifizierungstoken werden bereitgestellt und die Identitätsprüfung erfolgt über die bestehende Identitätsinfrastruktur der einzelnen Organisationen. Unternehmen müssen keinen zusätzlichen Autorisierungsserver erstellen oder verwalten, um ihre Anwendungen fertigzustellen.
• RBAC pro Server wird am Gateway durchgesetzt, nicht in der Anwendung: TrueFoundry erzwingt die Zugriffskontrolle am MCP-Gateway, bevor eine Anforderung die MCP-Serveranwendungslogik erreicht, und stellt sicher, dass Zugriffsrichtlinien für mehrere MCP-Instanzen durchgesetzt werden, unabhängig davon, wie die einzelnen Anwendungsinstanzen entwickelt oder bereitgestellt werden.
• Bereichsbezogener Zugriff, der Organisationsrollen den Toolberechtigungen zuordnet: TrueFoundry unterstützt den Geltungsbereich der MCP-Autorisierung, wobei eine Gruppe wie Finance einer Gruppe von Tools und eine andere Gruppe wie Support einer anderen zugewiesen wird. Ein Finanzagent und ein Support-Agent können auf dieselbe MCP-Infrastruktur zugreifen und verfügen gleichzeitig über unterschiedliche Toolberechtigungen. Die Zuordnung zwischen Rollen und OAuth-Bereichen wird einmal auf der Plattform definiert und gilt für alle Instanzen.
• Einheitlicher Audit-Trail in Ihrer VPC: TrueFoundry bietet einen einzigen konsolidierten Audit-Trail innerhalb der VPC des Kunden für Ereignisse im Zusammenhang mit der Token-Validierung und Tool-Aufrufen. Sicherheitsteams haben Zugriff auf einen vollständigen, zeitkorrelierten Audit-Trail. Alle Ereignisse zur Token-Validierung und zum Aufrufen von Tools enthalten eine einheitliche Anforderungs-ID, sodass Ereignisse, die sich auf einen bestimmten Benutzer beziehen, in großen Sprachmodellen und externen Tools einfach identifiziert werden können.
• Plattformstandard, nicht teamspezifische Konfiguration: Die MCP-Authentifizierungs- und MCP-Autorisierungsfunktionen sind standardmäßig für alle Organisationen aktiviert. Diese Richtlinien werden beim Einsatz von KI-Agenten immer von MCP-Anwendungen übernommen, sodass Teams nicht ihre eigenen Richtlinien erstellen oder die richtige Authentifizierung auf jedem neuen MCP-Server implementieren müssen.

TrueFoundry bietet MCP-Authentifizierung und -Autorisierung als grundlegende Plattformfunktionen und nicht als individuelle Konfigurationslast für die Organisationen, die seine Tools verwenden.

Häufig gestellte Fragen

Was sind MCP-Authentifizierung und MCP-Autorisierung?

MCP-Authentifizierung und MCP-Autorisierung sind zwei separate Sicherheitskonzepte. Die MCP-Authentifizierung bestätigt die Identität des MCP-Clients, bevor der Zugriff gewährt wird. Dabei werden OAuth-Token oder API-Schlüssel verwendet. Die MCP-Autorisierung bestimmt, was der authentifizierte Client über OAuth-Bereiche und RBAC tun kann. Beide sind in jeder MCP-Serverbereitstellung in der Produktion erforderlich, um Sicherheitsrisiken durch unbefugten Zugriff zu verhindern.

Was ist der Unterschied zwischen Authentifizierung und Autorisierung in MCP?

Die MCP-Authentifizierung erfolgt einmal bei der Verbindung und verwendet den Autorisierungscodefluss oder den Ablauf der Client-Anmeldeinformationen, um die Identität zu überprüfen. Die MCP-Autorisierung wird bei jedem Tool-Aufruf während der Verbindung überprüft. OAuth-Bereiche und RBAC-Regeln werden auf jede Anfrage angewendet, die der AI-Agent über den MCP-Server stellt

Können Sie eine MCP-Autorisierung ohne Authentifizierung haben?

Ohne MCP-Authentifizierung ist keine sinnvolle MCP-Autorisierung möglich, da es keine authentifizierte Identität gibt, anhand derer Berechtigungen bewertet werden könnten. Ohne eine angemessene Authentifizierung zur Identitätsfeststellung hat der Autorisierungsserver keine Grundlage für die Ausgabe von Zugriffstoken oder die Anwendung einer Autorisierungslogik auf eingehende Anfragen von AI-Agenten oder autonomen Agenten.

Was kommt zuerst, MCP-Authentifizierung oder MCP-Autorisierung?

Die MCP-Authentifizierung steht immer an erster Stelle. Der Autorisierungsablauf stellt die Identität des MCP-Clients gegenüber dem Autorisierungsserver fest. Die MCP-Autorisierung erfolgt dann für jede nachfolgende Anfrage, nachdem die Client-Authentifizierung abgeschlossen ist und Zugriffstoken mit definierten OAuth-Bereichen ausgestellt wurden.

Unterstützt TrueFoundry das Mitbringen Ihres eigenen IdP?

Ja. TrueFoundry lässt sich in jeden OAuth 2.0-kompatiblen Identitätsanbieter oder OAuth-Autorisierungsserver integrieren, sodass Unternehmen ihre bestehende Identitätsinfrastruktur wiederverwenden können. Dazu gehört auch die Unterstützung externer Identitätsanbieter wie Okta und Azure AD, wodurch eine zentrale MCP-Authentifizierung auf allen MCP-Servern ermöglicht wird, ohne dass eine separate Autorisierungsserverkonfiguration erstellt werden muss.