MCP-Authentifizierung in Cursor: OAuth, API-Schlüssel und sichere Konfiguration (Leitfaden 2026)

Die MCP-Authentifizierung bestimmt, wie der KI-Agent von Cursor seine Identität nachweist, wenn er auf externe Tools und Dienste zugreift. Vernachlässigen Sie sie, läuft jeder MCP-Server entweder völlig ungeschützt oder verlässt sich auf einen statischen Token im Klartext. Machen Sie es richtig, verbindet sich der Agent mit GitHub, Slack oder Ihren internen APIs über Anmeldedaten, die im Scope begrenzt, rotierbar und auditierbar sind.

Die MCP-Spezifikation hat in ihrer Überarbeitung vom März 2025 die standardisierte OAuth 2.1-Autorisierung eingeführt. Im Juni 2025 folgte die formelle Trennung von MCP-Servern und Autorisierungsserver sowie die Pflicht für Protected Resource Metadata (RFC 9728). Die Überarbeitung vom November 2025 brachte schließlich Client ID Metadata Documents (CIMD) als bevorzugte Registrierungsmethode ein und machte PKCE für jeden Client unverzichtbar. Cursor hat die OAuth-Unterstützung in v1.0 bereits im Juni 2025 ausgeliefert und gehörte damit zu den ersten IDEs, die eine browserbasierte MCP-Authentifizierung anboten.

Zwei Gründe sprechen dafür, sich mit dem Authentifizierungsmodell von Cursor zu beschäftigen: Es steuert, worauf Ihr Agent zugreifen kann, und es definiert den Schadensradius, wenn etwas schiefgeht.

Wie MCP-Authentifizierung funktioniert

Die MCP-Authentifizierung ist auf der Transportschicht angesiedelt. Welcher Mechanismus zum Einsatz kommt, hängt davon ab, ob der Server lokal über stdio oder remote über Streamable HTTP läuft.

Stdio-Server handhaben die Authentifizierung vollständig außerhalb des MCP-Protokolls. Der Server-Prozess erbt Umgebungsvariablen von Cursor — in der Regel API-Schlüssel oder Token — und nutzt diese zur Authentifizierung gegenüber Upstream-Diensten wie der GitHub-API, einer Datenbank oder einem Cloud-Anbieter. Die MCP-Spezifikation ist hier eindeutig: Stdio-Implementierungen sollten Anmeldedaten aus der Umgebung beziehen, nicht aus einem OAuth-Flow.

Remote-Server über Streamable HTTP folgen einem anderen Pfad. Die MCP-Spezifikation empfiehlt OAuth 2.1, und der Handshake umfasst drei Parteien:

Cursor übernimmt die Rolle des OAuth-Clients. Der MCP-Server fungiert als OAuth 2.1 Resource Server — er validiert Token, stellt sie jedoch niemals aus. Ein Autorisierungsserver (Okta, Auth0, Azure AD oder ein vom MCP-Server-Betreiber betriebener Server) kümmert sich um die Benutzerauthentifizierung und gibt Token aus.

Hier ist der tatsächliche Ablauf: Cursor sendet eine Anfrage ohne Token an den MCP-Server. Der Server antwortet mit 401 Unauthorized und einem WWW-Authenticate-Header, der auf sein Protected Resource Metadata-Dokument verweist. Cursor ruft dieses Dokument ab, ermittelt den zuständigen Autorisierungsserver, registriert sich selbst (über Dynamic Client Registration oder CIMD) und öffnet ein Browserfenster für die Anmeldung.

Sobald Sie die Autorisierung erteilen, stellt der Autorisierungsserver einen Access-Token aus. Cursor speichert diesen Token und fügt ihn jeder nachfolgenden Anfrage bei.

PKCE (Proof Key for Code Exchange) begleitet den gesamten Ablauf. Cursor generiert vor dem Start ein code_verifier- und code_challenge-Paar. Selbst wenn es einem Angreifer gelingt, den Autorisierungscode unterwegs abzufangen, kann er ihn ohne den ursprünglichen Verifier nicht gegen einen Token eintauschen.

Authentifizierungsmethoden in Cursor

Cursor bietet Ihnen drei Möglichkeiten zur Authentifizierung von MCP-Servern. Jede deckt ein anderes Bereitstellungsszenario ab.

Umgebungsvariablen für stdio-Server

Die meisten lokalen MCP-Server weisen ihre Identität gegenüber Upstream-APIs über Umgebungsvariablen nach. Cursor injiziert diese beim Start in den Server-Prozess.

Das env-Feld nimmt Schlüssel-Wert-Paare auf. Cursor übergibt sie direkt an den gestarteten Prozess. Ihr Token erscheint weder in der Benutzeroberfläche noch in den Logs von Cursor. Er liegt jedoch im Klartext in der mcp.json. Wenn Sie diese Datei in Git committen, haben Sie Ihre Anmeldedaten an alle Beteiligten übertragen — oder noch schlimmer, an ein öffentliches Repository.

Abhilfe: Referenzieren Sie Umgebungsvariablen auf Systemebene mit der Syntax ${env:VARIABLE_NAME}, anstatt Rohwerte einzufügen:

Jetzt liegt der echte Token in Ihrem Shell-Profil oder einem Secrets Manager. Die Datei mcp.json enthält nur einen Zeiger, sodass Sie sie sicher unter Versionskontrolle stellen können.

Statische Header für Remote-Server

Manche Remote-Server unterstützen kein OAuth. Für diese können Sie einen statischen API-Schlüssel oder Bearer-Token in den HTTP-Headern übergeben. Cursor sendet diese Header mit jeder Anfrage an den Server-Endpunkt mit.

Die Referenzsyntax für Umgebungsvariablen funktioniert auch in Headern:

Statische Header sind denkbar einfach einzurichten. Sie bringen jedoch alle Nachteile langlebiger Anmeldedaten mit sich: kein Ablaufdatum, keine Begrenzung des Gültigkeitsbereichs pro Sitzung und bei einer Rotation müssen Sie die Konfigurationsdatei jedes Entwicklers anpassen.

OAuth 2.1 für Remote-Server

OAuth ist das, was die MCP-Spezifikation für Remote-Server tatsächlich empfiehlt, und Cursor v1.0 hat dafür native Unterstützung gebracht. So sieht der Ablauf von Anfang bis Ende aus:

1. Tragen Sie eine Remote-Server-URL in die mcp.json ein — ganz ohne Auth-Header.
2. Öffnen Sie Cursor Settings → Tools & MCP. Der Server erscheint dort mit einer blauen Schaltfläche Connect und dem Hinweis „Needs authentication“ unter seinem Namen.
3. Klicken Sie auf Connect. Cursor öffnet Ihren Standardbrowser mit der Anmeldeseite des Autorisierungsservers.
4. Melden Sie sich an und gewähren Sie die angeforderten Berechtigungen.
5. Nach der Autorisierung leitet der Browser an cursor://anysphere.cursor-mcp/oauth/callback weiter. Ihr Betriebssystem leitet diesen Callback zurück an Cursor, das den Autorisierungscode über PKCE mit S256 gegen Token eintauscht.
6. Die Tools des Servers erscheinen in der MCP-Tool-Liste und stehen dem Agenten zur Verfügung.

Die JSON-Konfiguration für einen OAuth-gestützten Server ist extrem schlank, weil sie wirklich minimal ist:

Keine Token. Keine Header. Cursor regelt alles über den Discovery-Ablauf der Spezifikation — die Protected Resource Metadata des Servers teilen Cursor mit, wohin es sich wenden muss, und PKCE sichert den Token-Austausch ab.

Auch Ein-Klick-Deep-Links harmonieren bestens mit OAuth. Klicken Sie auf einer Dokumentationsseite eines Servers auf den Link „Add to Cursor“, startet Cursor direkt den OAuth-Ablauf, falls der Server dies erfordert.

Sicherheitsrisiken bei der Authentifizierung

Die MCP-Authentifizierung bietet an jedem Punkt des Lebenszyklus von Anmeldedaten Angriffsfläche: bei der Speicherung, der Übertragung, dem Austausch und dem Widerruf. Mehrere kritische Schwachstellen haben dies im Laufe des Jahres 2025 deutlich gemacht.

CVE-2025-6514: Befehlsinjektion über OAuth-Discovery

JFrog Security Research deckte eine kritische Schwachstelle (CVSS 9.6) in mcp-remote auf, einem populären npm-Paket, das OAuth-Verbindungen für MCP-Clients — einschließlich Cursor — weiterleitete. Das Problem? Das Paket übernahm die URL authorization_endpoint von jedem MCP-Server, mit dem es sich verband, ohne sie zu bereinigen.

Ein böswilliger Serverbetreiber konnte Shell-Befehle in diese Endpunkt-URL einschleusen. Wenn mcp-remote versuchte, die URL in einem Browser zu öffnen, führte das Betriebssystem die eingebetteten Befehle aus, anstatt eine Webseite zu laden.

Betroffen waren die Versionen 0.0.5 bis 0.1.15 mit über 437.000 Downloads. Cloudflare, Hugging Face und Auth0 hatten in ihren MCP-Integrations-Dokus alle auf mcp-remote verwiesen. Der Fix erschien in Version 0.1.16.

Im Kern ging die Schwachstelle auf das Vertrauensmodell von OAuth zurück: Der MCP-Client fragte einen nicht vertrauenswürdigen Server „wohin soll ich meinen Benutzer zum Login schicken?“ und folgte der Antwort blind. Der Patch ergänzte eine URL-Validierung und -Bereinigung, bevor Daten an System-Handler übergeben wurden.

Account-Übernahme mit einem Klick bei Remote-MCP-Servern

Obsidian Security veröffentlichte eine Reihe von Schwachstellen zur Kontoübernahme mit einem Klick in produktiven MCP-Servern namhafter Organisationen. Das gemeinsame Muster dahinter: Die meisten MCP-Server agierten zugleich als OAuth-Proxies — sie nahmen einen Autorisierungscode von Cursor entgegen und tauschten ihn beim Upstream-Dienst gegen Token ein.

Das Problem war struktureller Natur. Diese Server versäumten es, OAuth-state-Parameter an Benutzersitzungen zu binden. Sie setzten Berechtigungsabfragen nicht ordnungsgemäß durch. Ein Angreifer konnte einen Link konstruieren, der einen Autorisierungscode an eine vom Angreifer kontrollierte Redirect-URI umleitete.

Obsidian reichte die Berichte zwischen Juli und August 2025 ein. Die Hersteller veröffentlichten bis September Patches. Das Update der MCP-Spezifikation vom November 2025 fügte explizite Sicherheitsrichtlinien hinzu, die genau diese Angriffsmuster abdecken. Anzumerken bleibt: Zum damaligen Zeitpunkt unterstützten nur 3 von 78 von Obsidian getesteten MCP-Autorisierungsserver tatsächlich CIMD. Die Einführung neuerer Spezifikationsmerkmale verläuft schleppend.

MCP-Client-Schwachstellen über OAuth-Flows

Obsidian wies zudem auf kritische Fehler in MCP-Clients selbst hin — Gemini-CLI, VS Code, Windsurf und Cherry Studio wiesen allesamt Mängel auf (CVE-2025-54074 sowie drei verwandte CVEs). Die Kategorie des Fehlers war Remote Code Execution (RCE) durch nachlässige Handhabung von Autorisierungs-URLs.

Wenn ein MCP-Client einen präparierten authorization_endpoint über den URL-Handler des Systems öffnete, konnte ein Angreifer beliebige Betriebssystembefehle auf dem Rechner des Entwicklers ausführen. Da die MCP-Autorisierungsspezifikation URL-Schemata nicht einschränkt, konnten file://-, javascript:- oder plattformspezifische Schemata passieren, wenn der Client die Validierung übersprang.

Klartext-Anmeldedaten in mcp.json

Das häufigste Risiko benötigt keine CVE-Nummer. Jeder API-Schlüssel, den Sie in mcp.json ablegen, liegt im Klartext auf Ihrem Dateisystem. Wenn diese Datei in einem Projektverzeichnis landet und jemand sie in Git committet, gelangt die Anmeldeinformation an alle Beteiligten — und bei einem öffentlichen Repository womöglich an jeden im Internet. Umgebungsvariablen erfordern zumindest Shell-Zugriff. Die Datei mcp.json ist jedoch eine versionierte Konfigurationsdatei, die Entwickler routinemäßig und oft gedankenlos teilen.

Entwicklung der MCP-Auth-Spezifikation

Die MCP-Autorisierungsspezifikation durchlief im Jahr 2025 drei große Überarbeitungen. Jede einzelne adressierte reale Schwachstellen, die in der Vorversion aufgedeckt wurden.

Die Überarbeitung vom Juni 2025 war der entscheidende Schritt. Vor dieser Änderung musste jeder Entwickler eines MCP-Servers eigene Autorisierungs-Endpunkte bauen. Das zwang praktisch jeden Server-Autor dazu, zum OAuth-Implementierer zu werden — eine denkbar schlechte Idee im Hinblick auf die Sicherheit. Die aktualisierte Spezifikation verlagerte die Token-Ausstellung auf dedizierte Identitätsanbieter (Okta, Auth0, Azure AD), was dem etablierten Standard der Enterprise-Authentifizierung entspricht.

Der Stand vom November 2025 widmete sich direkt der Client-Registrierung. DCR hatte oft Probleme bereitet, da die meisten Enterprise-Autorisierungsserver dies nicht standardmäßig aktivieren. CIMD umgeht dieses Hindernis: Jeder Client veröffentlicht ein Metadaten-Dokument unter einer bekannten URL, und Autorisierungsserver treffen Vertrauensentscheidungen allein auf Basis der Domain. Das ist sauberer, praktikabler und weitaus kompatibler mit abgesicherten Unternehmensumgebungen.

Enterprise-Authentifizierung mit einem MCP Gateway

Ein einzelner Entwickler kann den Überblick über eine Handvoll API-Schlüssel problemlos behalten. Ein ganzes Team kann das nicht. Zehn Entwickler mit jeweils fünf MCP-Servern erzeugen fünfzig separate Zugangsdaten-Setups — ohne zentrale Einblicke in Zugriffsrechte, ohne automatische Schlüsselrotation und ohne Audit-Trail.

Ein MCP Gateway bündelt all diese Aufgaben an einem Ort. Das MCP Gateway von TrueFoundry unterstützt drei Authentifizierungsmethoden bei der Registrierung von Upstream-MCP-Servern:

• No Auth: Für Demo-Umgebungen oder öffentliche APIs. Für die Produktion nicht geeignet.
• Static Header Auth: Für Server, die API-Schlüssel oder statische Token nutzen. Das Gateway verwaltet die Anmeldedaten zentral und fügt sie in jede ausgehende Anfrage ein.
• OAuth2 and DCR: Für Server, die OAuth implementieren. Das Gateway führt den kompletten OAuth-Flow aus, speichert benutzerspezifische Token und erneuert diese automatisch vor ihrem Ablauf.

Das Betriebsmodell ähnelt einem Single Sign-On, jedoch speziell für MCP. Entwickler authentifizieren sich einmalig bei TrueFoundry — entweder über einen Personal Access Token (PAT) oder den Identitätsanbieter ihrer Organisation (Okta, Azure AD). Das Gateway verknüpft diese Identität mit den passenden Downstream-Anmeldedaten für den jeweiligen MCP-Server. Einzelne Entwickler kommen mit einem OAuth-Token direkt überhaupt nicht mehr in Berührung.

Auf Administratorseite organisieren Sie Server in MCP Server Groups und vergeben Zugriffsrechte nach Teams oder Rollen. Ein Junior-Entwickler erhält beispielsweise Nur-Lese-Zugriff auf GitHub. Ein Senior Engineer bekommt vollen GitHub-Zugriff sowie Schreibrechte für JIRA. Das Gateway setzt diese Grenzen auf Protokollebene durch — nicht über Konfigurationsdateien nach dem Prinzip der Selbstverpflichtung.

Hier finden Sie eine detaillierte Anleitung zum Einrichten der Okta OAuth2-Authentifizierung mit MCP-Servern über das Gateway, einschließlich der Konfiguration von Autorisierungsservern, Scope-Verwaltung und Token-Refreshes.

Wichtigste Kriterien zur Evaluierung eines Gateways

Kriterium	Was sollten Sie evaluieren?	Priorität	TrueFoundry
Latenz	Erzeugt <10ms p95 Overhead für Time-to-First-Token?	Must-Have	✅ Unterstützt
Datenresidenz	Speichert Logs in Ihrer Region (EU/US)?	Abhängig vom Anwendungsfall	✅ Unterstützt
Latenzbasiertes Routing	Leitet automatisch basierend auf Echtzeit-Latenzen/Ausfällen um?	Must-Have	✅ Unterstützt
Schlüsselrotation & Widerruf	Schlüssel ohne Ausfallzeit rotieren oder widerrufen?	Must-Have	✅ Unterstützt
Schlüsselrotation & Widerruf	Schlüssel ohne Ausfallzeit rotieren oder widerrufen?	Must-Have	✅ Unterstützt
Schlüsselrotation & Widerruf	Schlüssel ohne Ausfallzeit rotieren oder widerrufen?	Must-Have	✅ Unterstützt
Schlüsselrotation & Widerruf	Schlüssel ohne Ausfallzeit rotieren oder widerrufen?	Must-Have	✅ Unterstützt
Schlüsselrotation & Widerruf	Schlüssel ohne Ausfallzeit rotieren oder widerrufen?	Must-Have	✅ Unterstützt

Evaluierungs-Checkliste für MCP Gateways

Ein praktischer Leitfaden für Plattform- & Infrastruktur-Teams

Best Practices für die MCP-Authentifizierung in Cursor

• Committen Sie niemals Secrets in mcp.json. Nutzen Sie die Syntax ${env:VAR} zur Referenzierung bei stdio-Servern. Greifen Sie bei Remote-Servern auf OAuth zurück. Falls statische Header Ihre einzige Option sind, referenzieren Sie Umgebungsvariablen auch dort.
• Bevorzugen Sie OAuth gegenüber statischen Token bei allen Remote-Verbindungen. OAuth-Token laufen ab. Sie lassen sich im Scope begrenzen und widerrufen. Statische Token bieten nichts davon.
• Pinnen Sie Ihre mcp-remote-Version, falls Sie darauf angewiesen sind. CVE-2025-6514 hat gezeigt, dass ein einzelner ungepatchter OAuth-Proxy Ihre gesamte Entwicklungsumgebung gefährden kann. Nutzen Sie npx -y mcp-remote@0.1.16 oder neuer — in der Produktion niemals @latest.
• Schränken Sie Token-Scopes strikt ein. Wenn Cursor Sie durch einen OAuth-Flow führt, gewähren Sie nur das absolute Minimum. Nur-Lese-Rechte für Code-Suchen; Schreibrechte nur dann, wenn der Agent tatsächlich Issues erstellen oder PRs mergen muss.
• Überprüfen Sie regelmäßig Ihre verbundenen Server. Navigieren Sie zu Cursor Settings → Tools & MCP und prüfen Sie die aktiven Einträge. Trennen Sie Verbindungen, die Sie nicht mehr benötigen. Jeder verbundene Server entspricht aktiven Zugangsdaten im Arbeitsspeicher.
• Halten Sie Cursor auf dem neuesten Stand. Jede Version bringt Verbesserungen bei der OAuth-Handhabung und Sicherheits-Patches mit sich. Eine veraltete Cursor-Version bedeutet, dass veralteter Authentifizierungscode auf Ihrem Rechner läuft.

Fazit

Die MCP-Authentifizierung in Cursor deckt ein breites Spektrum ab — von einem einfachen API-Schlüssel im Klartext innerhalb einer JSON-Datei bis hin zu einem vollständigen OAuth 2.1-Flow mit PKCE, dynamischer Registrierung und automatischer Token-Erneuerung. Die Wahl der passenden Methode hängt vom Bereitstellungsmodell des Servers und Ihren individuellen Sicherheitsanforderungen ab.

Für die lokale Entwicklung halten Umgebungsvariablen in Kombination mit der Syntax ${env:VAR} Anmeldedaten aus der Versionskontrolle fern. Bei Remote-Diensten erübrigt OAuth die manuelle Token-Verwaltung komplett. Für Teams oder Unternehmen zentralisiert ein MCP Gateway wie das von TrueFoundry die Speicherung von Anmeldedaten, setzt rollenbasierte Zugriffe durch und bietet einen vollständigen Audit-Trail über jede MCP-Verbindung hinweg.

Entdecken Sie das MCP Gateway von TrueFoundry oder buchen Sie eine Demo, um die zentrale MCP-Authentifizierung in der Praxis zu erleben.

Häufig gestellte Fragen (FAQ)

Welche Authentifizierungsmethoden unterstützt Cursor für MCP-Server?

Cursor unterstützt drei Methoden: Umgebungsvariablen, die in lokale stdio-Serverprozesse injiziert werden, statische HTTP-Header (Bearer-Token oder API-Schlüssel) für Remote-Server sowie OAuth 2.1 mit PKCE für Remote-Server, welche die MCP-Autorisierungsspezifikation umsetzen. Die OAuth-Unterstützung ist seit der Version Cursor v1.0 verfügbar, die im Juni 2025 erschienen ist.

Wie funktioniert OAuth für MCP in Cursor?

Wenn Sie einen Remote-MCP-Server hinzufügen, der OAuth erfordert, folgt Cursor der MCP-Autorisierungsspezifikation. Es ermittelt den Autorisierungsserver über Protected Resource Metadata (RFC 9728), registriert sich selbst als Client, öffnet Ihren Browser für die Anmeldung und Rechtevergabe und tauscht den Autorisierungscode anschließend mittels PKCE gegen Token ein. Cursor verwahrt die Token sicher und erneuert sie selbstständig, bevor sie ablaufen.

Ist es sicher, API-Schlüssel in der mcp.json zu speichern?

Das Eintragen von rohen API-Schlüsseln in die mcp.json bedeutet, dass Anmeldedaten im Klartext auf der Festplatte liegen. Wird diese Datei in eine Versionskontrolle übernommen, wird der Schlüssel offengelegt. Nutzen Sie stattdessen die Referenzsyntax ${env:VARIABLE_NAME} — sie bezieht Werte zur Laufzeit aus Ihren System-Umgebungsvariablen. Für Remote-Server ist OAuth zu bevorzugen, da es statische Anmeldedaten vollständig überflüssig macht.

Worin bestand die mcp-remote-Schwachstelle?

CVE-2025-6514 war eine kritische Command-Injection-Schwachstelle (CVSS 9.6) im npm-Paket mcp-remote, die die Versionen 0.0.5 bis 0.1.15 betraf. JFrog Security Research entdeckte, dass das Paket OAuth-Authorization-Endpoint-URLs ohne jegliche Bereinigung an System-Handler weiterleitete. Ein böswilliger MCP-Server konnte eine URL konstruieren, die beliebige OS-Befehle auf dem Rechner des Entwicklers ausführte. Version 0.1.16 enthielt den Fix.

Wie verwalten Unternehmen die MCP-Authentifizierung in großem Maßstab?

Mit einem MCP Gateway, das das gesamte Credential-Management übernimmt. Das Gateway von TrueFoundry speichert und aktualisiert OAuth-Tokens auf Benutzerbasis, ordnet organisatorische Identitäten den nachgelagerten MCP-Credentials zu und setzt rollenbasierte Zugriffsrichtlinien (RBAC) durch. Entwickler melden sich einmal an und müssen sich nie wieder mit einzelnen MCP-Server-Tokens auseinandersetzen.

Unterstützt Cursor CIMD für die OAuth-Client-Registrierung?

Stand Anfang 2026 noch nicht. Cursor stützt sich bei seinen OAuth-Flows weiterhin auf Dynamic Client Registration (DCR). Die MCP-Spezifikation vom November 2025 hat CIMD als bevorzugte Registrierungsmethode eingeführt, aber Forenbeiträge aus der Community von Januar 2026 legen nahe, dass das Feature noch nicht veröffentlicht wurde. In der Zwischenzeit funktioniert DCR für die meisten OAuth-fähigen MCP-Server weiterhin problemlos.