MCP-Authentifizierung erklärt: Wie sie funktioniert und warum sie wichtig ist

Die MCP-Authentifizierung und -Autorisierung waren nicht immer so sicher wie heute. Als MCP mit der Einführung von MCP begann, erfolgte die Authentifizierung in der Regel über API-Schlüssel, die oft in einer Konfigurationsdatei oder als Umgebungsvariablen enthalten waren und so statischen, gemeinsamen Zugriff ohne Bereichsbegrenzung ermöglichten. Wenn dieser Schlüssel durchsickern würde, würde er einem böswilligen Benutzer vollen Zugriff gewähren, ohne dass er nachverfolgen oder kontrollieren könnte, was getan wurde.

Die MCP-Spezifikation wurde schnell weiterentwickelt, um diesem Problem Rechnung zu tragen:

• März 2025: OAuth 2.1 wurde als Standard für die Authentifizierung einer Anwendung oder eines Benutzers gegen eine API definiert.
• Juni 2025: MCP-Server wurden als OAuth-Ressourcenserver neu definiert, und die Möglichkeit, Token auszustellen, wurde an externe Identitätsanbieter übertragen.
• November 2025: PKCE wurde für alle clientseitigen Anwendungen verpflichtend, und CIMD wurde so definiert, dass jede Client-Instanz eindeutig identifiziert werden kann.

In weniger als einem Jahr wurde die MCP-Authentifizierungsmethode von statischen Geheimnissen auf ein Modell umgestellt, das modernen Unternehmensidentitätssystemen entspricht.

In diesem Leitfaden wird beschrieben, was MCP-Authentifizierung ist, wie sie funktioniert, welche Ansätze zu ihrer Implementierung möglich sind, wo Implementierungen schief gehen und wie sie in großem Maßstab richtig implementiert werden kann.

Was ist MCP-Authentifizierung?

Die MCP-Authentifizierung ist der Prozess, bei dem ein MCP-Server die Identität eines Anforderers überprüft, bevor ein Tool ausgeführt wird.

Ohne MCP-Authentifizierung könnte jeder MCP-Client, der einen MCP-Server erreichen könnte, seine Tools aufrufen, unabhängig von der Identität, Rolle oder Absicht dieses Clients. Wenn die aufgerufenen Tools eine Verbindung zu kritischen externen Systemen wie CRMs, Datenbanken oder Cloud-Diensten herstellen, würde dies einen uneingeschränkten Zugang zu sensiblen Produktionsdaten ermöglichen.

Dies ist kein theoretisches Risiko. Eine CVSS 9.6-Schwachstelle im mcp-remote-Paket ermöglichte es böswilligen MCP-Servern, den OAuth-Fluss innerhalb des Pakets zu nutzen, um beliebige Betriebssystembefehle remote auszuführen, was sich auf Hunderttausende von Downloads auswirkte.

Die MCP-Authentifizierung erfolgt über die Transportschicht, bevor das Tool ausgeführt wird. Die Art der Ausführung hängt davon ab, wie der MCP-Server bereitgestellt wird:

• STDIO-Verkehr (lokale Server): Wird als lokaler Prozess ausgeführt; die MCP-Authentifizierung kann Umgebungsvariablen oder Systemanmeldeinformationen außerhalb von MCP verwenden.
• Streambares HTTP (Remoteserver): Läuft über das Netzwerk ohne gemeinsame Vertrauensstellung zwischen MCP-Client und -Server. Die MCP-Authentifizierung erfolgt mithilfe von OAuth 2.1, wobei jeder Anfrage Zugriffstoken beigefügt sind.

In der Praxis:

• Lokale Entwicklung: Umweltbezogene Qualifikationen können ausreichend sein.
• Remote-Produktionssysteme: OAuth 2.1 ist für eine korrekte Authentifizierung erforderlich.

Die drei Arten der MCP-Authentifizierung

Authentifizierungsmethoden, die je nach Umgebung und Risikotoleranz in verschiedenen MCP-Bereitstellungen verwendet werden

API-Schlüssel und statische Token

Es ist eine einfache Methode, bei jeder Anfrage einen vorab vereinbarten Schlüssel zu übergeben.

Genehmigung: Inhaber sk-xxxx

Wenn es funktioniert:

• In der lokalen Entwicklung und durch ein internes Tool, das innerhalb einer genau definierten Netzwerkgrenze arbeitet.

Einschränkungen:

• Statische Token haben kein Verfallsdatum
• Statische Token haben keine Benutzeridentität
• Keine granularen Berechtigungen
• Statische Token können über Protokolle oder Versionskontrolle durchgesickert werden, was ziemlich riskant ist.
• Wenn statische Token verfügbar gemacht werden, bleibt die vollständige Zugriffskontrolle für das zugehörige System aktiv, bis sie manuell deaktiviert wird

OAuth 2.1 mit PKCE (Standard für Remote-MCP-Server)

Ab dem MCP-Spezifikationsupdate vom März 2025 ist OAuth 2.1 mit PKCE der Standard für die Sicherung von Remote-MCP-Servern per MCP-Authentifizierung. Anstelle statischer Anmeldeinformationen verwendet dieser Ansatz einen sicheren, tokenbasierten Autorisierungsablauf, der Streamable HTTP ermöglicht.

So funktioniert's:

• Erkennung von Metadaten: Der MCP-Client versucht, die erforderlichen Autorisierungsserver-Metadaten vom Server ohne Zugriffstoken zu ermitteln, und erhält eine 401-Antwort. Das Metadatendokument für geschützte Ressourcen teilt dem Client mit, zu welchem Autorisierungsserver eine Verbindung hergestellt werden soll und welche erforderlichen Bereiche verfügbar sind.
• Registrierung als Kunde: Der MCP-Client registriert sich beim Autorisierungsserver. Die Standardmethode seit November 2025 erfolgt über das CIMD-Protokoll. Der Client veröffentlicht seine Client-ID-Metadaten auf einer öffentlichen URL, die er kontrolliert, und der Autorisierungsserver führt eine Laufzeitvalidierung der Client-Informationen durch.
• Autorisierungscode: Der Client öffnet den Browser des Benutzers, fordert den Benutzer auf, sich anzumelden und seine Zustimmung zu geben, und erhält vom Autorisierungsserver einen Autorisierungscode, um in seinem Namen zu handeln.
• Ausgabe von Zugriffstokens: Der Client tauscht den Autorisierungscode mithilfe des Autorisierungscodeflusses gegen ein Zugriffstoken aus, das auf die angeforderte Ressource beschränkt ist, und fügt dieses Token jeder MCP-Anfrage bei.

Warum PKCE wichtig ist:

• PKCE schützt vor Abfangangriffen, indem es sicherstellt, dass der Benutzer, der die MCP-Authentifizierung durchführt, dieselbe Person ist, die sie initiiert hat.
• PKCE ist ab November 2025 für alle MCP-Clients gemäß der aktuellen MCP-Spezifikation erforderlich.

Umgebungsbasierte Anmeldeinformationen (STDIO-Server)

Lokale MCP-Server erben Anmeldeinformationen aus ihrer eigenen Laufzeitumgebung.

Vorteile:

• Einfach einzurichten ohne externen Autorisierungsfluss.

Nachteile:

• Anmeldeinformationen sind für jeden Prozess zugänglich, der auf das MCP-System zugreifen kann, wodurch ein Risiko für alle Datenquellen besteht.
• Ohne eine zentrale Autorisierungslogik ist die Verwaltung über mehrere Personen oder Teams hinweg schwierig.
• Keine zentrale Verwaltung oder Zugriffskontrolle.

In Produktionsumgebungen sollten Sie Ihre Anmeldeinformationen mithilfe eines sicheren Tresors dynamisch abrufen, anstatt sie im Klartext zu speichern.

So funktioniert die MCP OAuth 2.1-Authentifizierung Schritt für Schritt

Wenn ein MCP-Client eine Verbindung zu einem geschützten MCP-Server herstellt, tritt der folgende MCP-Flow auf:

• Schritt 1 — Der Client stellt eine Verbindung her, der Server lehnt ab: Der MCP-Client versucht eine Anfrage ohne Token. Der Server reagiert im Rahmen der Autorisierungsservererkennung mit einem Fehler 401 Unauthorized und einem Zeiger auf die URL für geschützte Ressourcenmetadaten.
• Schritt 2 — Der Client ruft Metadaten ab: Der Metadaten-Endpunkt gibt an, welcher Autorisierungsserver verwendet werden soll, welche OAuth-Bereiche verfügbar sind und wo der Token-Endpunkt zu finden ist.
• Schritt 3 — Der Client registriert sich und beginnt mit dem OAuth-Ablauf: Der Client identifiziert sich anhand von CIMD und seinem Client-ID-Metadatendokument, erstellt einen PKCE-Codeverifier und eine Code-Challenge und leitet dann den Browser des Benutzers zur Anmeldeseite des Autorisierungsservers weiter.
• Schritt 4 — Der Benutzer authentifiziert sich und erhält den Autorisierungscode: Der Benutzer meldet sich an und stimmt zu. Der Autorisierungsserver gibt einen Autorisierungscode zurück, den der Client mithilfe des ursprünglichen Codeverifizierers gegen ein kurzlebiges Zugriffstoken mit Gültigkeitsbereich austauschen kann.
• Schritt 5 — Der Client ruft den MCP-Server mit dem Bearer-Token auf: Jede MCP-Anfrage enthält das Zugriffstoken im Authorization Bearer-Header. Der MCP-Server validiert den Aussteller, die Zielgruppe, den Ablauf und die OAuth-Bereiche. Wenn das Zugriffstoken nicht über die erforderlichen Bereiche verfügt, antwortet der Server mit 403 und fordert eine zusätzliche Benutzerautorisierung an. Diese Funktion wurde im November 2025 eingeführt.

Wo geht die MCP-Authentifizierung immer noch schief?

Viele Bereitstellungen bergen ernsthafte MCP-Sicherheitsrisiken durch unsachgemäße MCP-Authentifizierung und Autorisierungsimplementierung, selbst wenn OAuth verwendet wird.

• Statische Token in Konfigurationsdateien: API-Schlüssel, die in Git-Repositorys übertragen, in mcp.json- oder .env-Dateien geteilt und vergessen wurden. Eine einzelne kompromittierte OAuth-Client-ID bietet unbegrenzten Zugriff und läuft nie ab, wodurch eine dauerhafte Quelle für unbefugten Zugriff entsteht.
• Überzulässige OAuth-Bereiche: Benutzer fordern während der Konfiguration eine große Anzahl von OAuth-Bereichen an, schränken sie jedoch nicht ein, wenn die Anwendung ausgeführt wird. Ein AI-Agent, der als schreibgeschützt konfiguriert ist, sollte mit einem Zugriffstoken mit Lesebereich statt mit einem Lese-/Schreib-/Löschen-Token gespeichert werden.
• Keine Token-Rotation in selbstverwalteten Bereitstellungen: Langlebige OAuth-Token, die für selbstverwaltete Bereitstellungen ohne Rotationsprozess ausgegeben werden. Wenn ein Token kompromittiert wird, bleibt es als gültiges Inhaber-Token funktionsfähig, bis es von jemandem manuell deaktiviert wird.
• Kein Audit-Trail für Tool-Aufrufe: Wenn ein Token ausgegeben wird und auf externe Tools zugegriffen wird, gibt es keinen Datensatz, der angibt, wer die ursprüngliche MCP-Anfrage gestellt hat, was eine Ursachenuntersuchung für Mitglieder des Sicherheitsteams unmöglich macht.

Die meisten dieser Probleme werden behoben, wenn Unternehmen von statischen Schlüsseln zu OAuth 2.1 migrieren, was kurzlebige Zugriffstoken, bereichsbegrenzte OAuth-Bereiche und eine zentrale Auditprotokollierung über den Autorisierungsserver ermöglicht.

MCP-Authentifizierungsanforderungen für Unternehmen und wie TrueFoundry sie löst

TrueFoundry beseitigt die Komplexität der Verwaltung mehrerer Formen der MCP-Authentifizierung und -Autorisierung in einzelnen Teams und wendet einheitliche Kontrollen auf allen MCP-Servern über eine einzige MCP-Gateway-Ebene an.

Eine Demo buchen um zu verstehen, wie MCP mit der Authentifizierung auf Infrastrukturebene umgeht

Häufig gestellte Fragen

Was ist MCP-Authentifizierung? 

Bei der MCP-Authentifizierung wird die Identität einer Entität überprüft, die versucht, eine Verbindung zu einem MCP-Server herzustellen. Dabei werden je nach Bereitstellungskontext OAuth-Token, API-Schlüssel oder Umgebungsvariablen verwendet. Es ermöglicht nur verifizierten KI-Agenten und MCP-Clients den Zugriff auf Tools und externe Dienste und bildet die erste Ebene der MCP-Authentifizierung und -Autorisierung in jedem Produktionssystem.

Benötigt MCP OAuth? 

Nicht in jedem Fall. Ein lokaler STDIO-Transportserver implementiert möglicherweise keinen formellen OAuth-Fluss. Jeder Remote-MCP-Server, der produktionssensitive Daten verarbeitet, oder externe Tools sollten jedoch OAuth 2.1 mit PKCE als Standardautorisierungsmechanismus gemäß der aktuellen MCP-Spezifikation verwenden, um eine ordnungsgemäße MCP-Authentifizierung und Autorisierungsdurchsetzung zu gewährleisten.

Hat MCP eine Authentifizierung? 

MCP unterstützt MCP-Authentifizierung und -Autorisierung, und die Methode hängt von der Serverumgebung ab. Remoteserver verwenden OAuth 2.1 PKCE als Standardautorisierungsablauf. Lokale STDIO-Transportserver authentifizieren sich mit Anmeldeinformationen aus Umgebungsvariablen oder dem Host-Prozess. Die MCP-Spezifikation schreibt OAuth 2.1 ab März 2025 offiziell als Standard für Remote-Bereitstellungen vor.

Was sind die Arten der MCP-Authentifizierung? 

Für die MCP-Authentifizierung und -Autorisierung gibt es drei gängige Methoden: statische API-Schlüssel für interne Anwendungsfälle oder Entwicklungszwecke, OAuth 2.1 mit PKCE für alle Remote-MCP-Serverbereitstellungen, wie in der MCP-Spezifikation vorgeschrieben, und umgebungsbasierte Anmeldeinformationen über Umgebungsvariablen für lokale STDIO-Transportserver, für die kein formeller OAuth-Client-Registrierungsablauf erforderlich ist.

Wie funktioniert die MCP-Authentifizierung? 

Wenn ein MCP-Client eine Verbindung zu einem geschützten MCP-Server herstellt, gibt der Server eine 401 mit einem Zeiger auf sein geschütztes Ressourcen-Metadatendokument zurück. Der Client ermittelt den Autorisierungsserver, registriert sich mithilfe von CIMD, schließt den Autorisierungscodefluss mit PKCE ab und erhält ein bereichsbezogenes Zugriffstoken. Dieses Token ist in jeder eingehenden Anforderung zur Tokenvalidierung enthalten, bevor ein Toolaufruf zulässig ist.

Wie geht TrueFoundry mit der MCP-Authentifizierung um? 

Über das MCP-Gateway zentralisiert TrueFoundry die MCP-Authentifizierung und -Autorisierung, indem es in Unternehmensidentitätsanbieter integriert wird und die automatische Ausgabe, Rotation und Token-Validierung von Zugriffstokens übernimmt. OAuth-Bereiche und RBAC-Richtlinien werden auf der Gateway-Ebene auf allen MCP-Servern durchgesetzt, wobei strukturierte Auditprotokolle in der Kunden-VPC gespeichert werden, um die Einhaltung der Vorschriften durch KI-Agenten und externe Dienste sicherzustellen.