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

Die MCP-Authentifizierung bestimmt, wie der KI-Agent von Cursor beweist, wer er ist, wenn er auf externe Tools und Dienste zugreift. Wenn Sie es überspringen, läuft jeder MCP-Server entweder völlig offen oder ist auf ein statisches Token angewiesen, das im Klartext gespeichert ist. Wenn Sie alles richtig machen, stellt der Agent eine Verbindung zu GitHub, Slack oder Ihren internen APIs her, und zwar mit Anmeldeinformationen, die einen bestimmten Geltungsbereich haben, rotierbar und überprüfbar sind.

Das MCP-Spezifikation hat die standardisierte OAuth 2.1-Autorisierung in seiner März 2025 Revision. Juni 2025 gefolgt von der formellen Trennung von MCP-Servern von Autorisierungsservern und der Anforderung von Protected Resource Metadata (RFC 9728). Dann die Revision vom November 2025 führte Client ID Metadata Documents (CIMD) als bevorzugte Registrierungsmethode ein und machte PKCE für jeden Kunden nicht verhandelbar. Cursor hat die OAuth-Unterstützung in ausgeliefert v1.0 bereits im Juni 2025 und gehört damit zu den ersten IDEs, die eine browserbasierte MCP-Authentifizierung anbieten.

Zwei Dinge machen es lohnenswert, das Authentifizierungsmodell von Cursor zu verstehen: Es bestimmt, was Ihr Agent anfassen kann, und es definiert den Explosionsradius, wenn etwas kaputt geht.

So funktioniert die MCP-Authentifizierung

Die MCP-Authentifizierung befindet sich auf der Transportebene. Welchen Mechanismus Sie erhalten, hängt davon ab, ob der Server lokal über stdio oder remote über Streamable HTTP läuft.

Studio-Server behandelt die Authentifizierung außerhalb des MCP-Protokolls vollständig. Der Serverprozess erbt Umgebungsvariablen von Cursor — normalerweise API-Schlüssel oder Token — und verwendet diese, um sich gegenüber Upstream-Diensten wie der GitHub-API, einer Datenbank oder einem Cloud-Anbieter zu authentifizieren. Die MCP-Spezifikation ist hier explizit: stdio-Implementierungen sollten Anmeldeinformationen aus der Umgebung abrufen, nicht aus einem OAuth-Flow.

Remoteserver auf Streamable HTTP folge einem anderen Weg. Die MCP-Spezifikation empfiehlt OAuth 2.1, und am Handshake sind drei Parteien beteiligt:

Cursor spielt die Rolle des OAuth-Clients. Der MCP-Server fungiert als OAuth 2.1-Ressourcenserver — er validiert Tokens, gibt sie aber nie aus. Ein Autorisierungsserver (Okta, Auth0, Azure AD oder einer, den der MCP-Serverbetreiber ausführt) kümmert sich um die Benutzerauthentifizierung und verteilt Token.

Hier ist die eigentliche Sequenz. Der Cursor löst eine Anfrage an den MCP-Server aus, an die kein Token angehängt ist. Der Server kommt mit 401 Unauthorized und einem WWW-Authenticate-Header zurück, der auf seinen Geschützte Ressourcenmetadaten Dokument. Der Cursor erfasst das Dokument, ermittelt, mit welchem Autorisierungsserver er kommunizieren soll, registriert sich selbst (über Dynamic Client Registration oder CIMD) und führt Sie in ein Browserfenster, in dem Sie sich anmelden können.

Nach der Autorisierung gibt der Autorisierungsserver ein Zugriffstoken aus. Der Cursor speichert dieses Token und hängt es an jede nachfolgende Anfrage an.

STÜCK (Proof Key for Code Exchange) durchläuft den gesamten Ablauf. Der Cursor generiert ein Code_Verifier- und ein Code_Challenge-Paar, bevor es losgeht. Selbst wenn es einem Angreifer gelingt, den Autorisierungscode während des Fluges abzufangen, kann er ihn nicht gegen ein Token ohne den ursprünglichen Verifier eintauschen.

Authentifizierungsmethoden im Cursor

Cursor bietet Ihnen drei Möglichkeiten, MCP-Server zu authentifizieren. Jedes ist einem anderen Einsatzszenario zugeordnet.

Umgebungsvariablen für stdio Server

Die meisten lokalen MCP-Server beweisen ihre Identität gegenüber Upstream-APIs durch Umgebungsvariablen. Der Cursor injiziert diese beim Start in den Serverprozess.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

Das Feld env akzeptiert Schlüssel-Wert-Paare. Der Cursor leitet sie direkt an den erzeugten Prozess weiter. Ihr Token wird nicht in der Benutzeroberfläche oder in den Protokollen des Cursors angezeigt. Aber es befindet sich im Klartext in mcp.json. Übergeben Sie diese Datei an Git und schon haben Sie Ihre Zugangsdaten an jeden Mitarbeiter gesendet — oder schlimmer noch, an ein öffentliches Repo.

Schadensbegrenzung: Referenzieren Sie Umgebungsvariablen auf Systemebene mithilfe der $ {env:variable_name} -Syntax, anstatt Rohwerte einzufügen:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}"
      }
    }
  }
}

Jetzt befindet sich das echte Token in Ihrem Shell-Profil oder einem Secrets Manager. Die mcp.json-Datei enthält nur einen Zeiger, sodass Sie sie sicher versionssteuern können.

Statische Header für Remoteserver

Einige Remoteserver unterstützen OAuth nicht. Für diese können Sie einen statischen API-Schlüssel oder ein Bearer-Token in HTTP-Headern übergeben. Cursor versendet diese Header zusammen mit jeder Anfrage an den Serverendpunkt.

{
  "mcpServers": {
    "internal-api": {
      "url": "https://mcp.internal.company.com/v1",
      "headers": {
        "Authorization": "Bearer <YOUR_API_KEY>"
      }
    }
  }
}

Die Referenzsyntax für Umgebungsvariablen funktioniert auch in Headern:

{
  "mcpServers": {
    "internal-api": {
      "url": "https://mcp.internal.company.com/v1",
      "headers": {
        "Authorization": "Bearer ${env:INTERNAL_API_KEY}"
      }
    }
  }
}

Statische Header sind kinderleicht einzurichten. Sie haben auch alle Nachteile langlebiger Anmeldeinformationen: kein Ablaufdatum, kein Umfang pro Sitzung, und wenn Sie sie wechseln, müssen Sie die Konfigurationsdatei jedes Entwicklers bearbeiten.

OAuth 2.1 für Remoteserver

OAuth ist das, was die MCP-Spezifikation eigentlich für Remote-Server empfiehlt, und Cursor v1.0 bot native Unterstützung. So sieht das Erlebnis von Anfang bis Ende aus:

1. Fügen Sie eine Remoteserver-URL in mcp.json ein — es werden keine Auth-Header benötigt.
2. Offen Cursoreinstellungen → Tools & MCP. Der Server erscheint mit einem blauen Verbinde Schaltfläche und ein Etikett „Authentifizierung erforderlich“ unter dem Namen.
3. Treffer Verbinde. Der Cursor öffnet Ihren Standardbrowser und öffnet die Anmeldeseite des Autorisierungsservers.
4. Loggen Sie sich ein und gewähren Sie die angeforderten Berechtigungen.
5. Nach der Autorisierung leitet der Browser zu cursor: //anysphere.cursor-mcp/oauth/callback weiter. Ihr Betriebssystem leitet den Callback zurück an Cursor weiter, der den Autorisierungscode gegen Token über PKCE gegen S256 austauscht.
6. Die Tools des Servers werden in der MCP-Tools-Liste angezeigt und stehen für den Anruf des Agenten bereit.

Die JSON-Konfiguration für einen OAuth-gestützten Server sieht minimal aus, weil sie ist minimal:

{
  "mcpServers": {
    "linear": {
      "url": "https://mcp.linear.app/mcp"
    }
  }
}

Keine Tokens. Keine Header. Der Cursor kümmert sich während des Erkennungsablaufs der Spezifikation um alles — die geschützten Ressourcenmetadaten des Servers teilen dem Cursor mit, wohin er gehen soll, und PKCE sperrt den Token-Austausch.

Deeplinks mit einem Klick lassen sich auch gut mit OAuth kombinieren. Klicken Sie auf der Dokumentseite eines Servers auf einen Link „Zum Cursor hinzufügen“, und Cursor löst den OAuth-Fluss sofort aus, falls der Server ihn benötigt.

Sicherheitsrisiken bei der Authentifizierung

Die MCP-Authentifizierung eröffnet an jedem Punkt des Lebenszyklus der Anmeldeinformationen eine Angriffsfläche: wie Sie sie speichern, senden, austauschen und widerrufen. Das wurde im Laufe des Jahres 2025 durch mehrere fiese Sicherheitslücken deutlich.

CVE-2025-6514: Befehlsinjektion über OAuth Discovery

JFrog Sicherheitsforschung Ich habe einen kritischen Fehler (CVSS 9.6) in mcp-remote gefunden, einem beliebten npm-Paket, das OAuth-Verbindungen für MCP-Clients als Proxy bereitstellt — einschließlich Cursor. Das Problem? Das Paket hat die authorization_endpoint URL von dem MCP-Server abgerufen, mit dem es verbunden war, und hat sie nie bereinigt.

Ein betrügerischer Serverbetreiber könnte Shell-Befehle in diese Endpunkt-URL stopfen. Als mcp-remote versuchte, die URL in einem Browser zu öffnen, führte das Betriebssystem die eingebetteten Befehle aus, anstatt eine Webseite zu laden.

Die Versionen 0.0.5 bis 0.1.15 waren betroffen. Über 437.000 Downloads. Cloudflare, Hugging Face und Auth0 hatten in ihren MCP-Integrationsdokumenten alle auf mcp-remote hingewiesen. Das Update ist in Version 0.1.16 gelandet.

Im Kern ging die Sicherheitslücke auf das OAuth-Trust-Modell zurück: Der MCP-Client fragte einen nicht vertrauenswürdigen Server: „Wohin soll ich meinen Benutzer schicken, um sich anzumelden?“ und folgte dann blind der Antwort. Der Patch fügte eine URL-Validierung und -Bereinigung hinzu, bevor etwas an die Systemhandler weitergegeben wurde.

Kontoübernahme auf Remote-MCP-Servern mit einem Klick

Obsidian-Sicherheit hat eine Reihe von Sicherheitslücken bei Kontoübernahme mit einem Klick auf Produktions-MCP-Servern bekannter Unternehmen behoben. Der rote Faden, der sich durch alle zieht: Die meisten MCP-Server sind gleichzeitig OAuth-Proxys — sie nehmen einen Autorisierungscode von Cursor und tauschen ihn beim Upstream-Dienst gegen Token ein.

Was schief gelaufen ist, war strukturell. Diese Server konnten die OAuth-Zustandsparameter nicht an Benutzersitzungen binden. Sie haben die Zustimmung nicht ordnungsgemäß durchgesetzt. Ein Angreifer könnte einen Link erstellen, der einen Autorisierungscode zu einer vom Angreifer kontrollierten Weiterleitungs-URI weiterleitet.

Obsidian reichte die Berichte zwischen Juli und August 2025 ein. Die Anbieter haben sie im September gepatcht. Das MCP-Spezifikationsupdate vom November 2025 fügte explizite Sicherheitsrichtlinien hinzu, die genau diese Angriffsmuster abdeckten. Bemerkenswert: Nur 3 von 78 MCP-Autorisierungsservern, die Obsidian getestet hatte, unterstützten zu diesem Zeitpunkt tatsächlich CIMD. Die Einführung neuerer Spezifikationsfunktionen verlief langsam.

MCP-Client-Schwachstellen über OAuth-Flows

Obsidian wurde ebenfalls markiert Kritische Fehler in den MCP-Clients selbst — Gemini-CLI, VS Code, Windsurf und Cherry Studio — hatten alle Probleme (CVE-2025-54074 und drei verwandte CVEs). Die Fehlerkategorie war Remotecodeausführung durch schlampige Handhabung von Autorisierungs-URLs.

Wenn ein MCP-Client einen handgefertigten authorization_endpoint über den URL-Handler des Systems öffnete, konnte ein Angreifer beliebige Betriebssystembefehle auf dem Computer des Entwicklers ausführen. Die MCP-Autorisierungsspezifikation schränkt URL-Schemas nicht ein, sodass file://, javascript: oder plattformspezifische Schemas passieren könnten, wenn der Client die Validierung übersprungen hat.

Klartext-Anmeldeinformationen in mcp.json

Das häufigste Risiko benötigt keine CVE-Nummer. Jeder API-Schlüssel, den Sie in mcp.json eingeben, befindet sich im Klartext auf Ihrem Dateisystem. Wenn diese Datei in einem Projektverzeichnis landet und jemand sie an Git überträgt, werden die Zugangsdaten an jeden Mitarbeiter weitergegeben — und möglicherweise an jede Person im Internet, wenn es sich um ein öffentliches Repo handelt. Für Umgebungsvariablen ist zumindest Shell-Zugriff erforderlich. mcp.json ist jedoch eine versionierte Konfigurationsdatei, die Entwickler routinemäßig gemeinsam nutzen, ohne zweimal darüber nachzudenken.

Wie sich die MCP Auth Spec entwickelt hat

Die MCP-Autorisierungsspezifikation wurde 2025 dreimal grundlegend überarbeitet. In jedem wurden echte Fehler behoben, die in der vorherigen Version aufgedeckt wurden.

Die Revision vom Juni 2025 war die große. Vor dieser Änderung musste jeder MCP-Serverentwickler seine eigenen Autorisierungsendpunkte erstellen. Das zwang praktisch jeden Serverautor dazu, ein OAuth-Implementierer zu werden — eine schreckliche Idee, wenn Sie Wert auf Sicherheit legen. Durch die aktualisierte Spezifikation wurde die Token-Ausgabe an dedizierte Identitätsanbieter (Okta, Auth0, Azure AD) verlagert. So funktioniert Enterprise Auth seit Jahren.

Im November 2025 wurde die Kundenregistrierung direkt in Angriff genommen. DCR hatte Kopfschmerzen bereitet, da die meisten Autorisierungsserver für Unternehmen es nicht sofort aktivieren. CIMD umgeht dieses Problem: Jeder Client veröffentlicht ein Metadatendokument unter einer bekannten URL, und Autorisierungsserver treffen Vertrauensentscheidungen allein auf der Grundlage der Domain. Sauberer, praktischer und benutzerfreundlicher für gesperrte Unternehmensumgebungen.

Unternehmensauthentifizierung mit einem MCP Gateway

Ein einzelner Entwickler kann ohne großen Aufwand den Überblick über eine Handvoll API-Schlüssel behalten. Ein Team kann das nicht. Zehn Entwickler, die jeweils fünf MCP-Server verwenden, erstellen fünfzig separate Anmeldeinformationssysteme — kein zentraler Überblick darüber, wer auf was zugreifen kann, keine automatische Schlüsselrotation, kein Audit-Trail.

Ein MCP Gateway vereint all das an einem Ort. Das MCP-Gateway von TrueFoundry unterstützt drei Authentifizierungsmethoden, wenn Sie Upstream-MCP-Server registrieren:

• Keine Authentifizierung: Für Demo-Umgebungen oder öffentliche APIs. Nicht für die Produktion geeignet.
• Statische Header-Authentifizierung: Für Server, die API-Schlüssel oder statische Token verwenden. Das Gateway speichert die Anmeldeinformationen zentral und fügt sie in jede ausgehende Anfrage ein.
• OAuth2 und DCR: Für Server, die OAuth implementieren. Das Gateway führt den gesamten OAuth-Flow aus, speichert benutzerspezifische Token und aktualisiert sie automatisch, bevor sie ablaufen.

Das Betriebsmodell ähnelt Single Sign-On, jedoch für MCP. Entwickler authentifizieren sich einmal bei TrueFoundry — entweder über ein Personal Access Token (PAT) oder über den Identitätsanbieter ihrer Organisation (Okta, Azure AD). Das Gateway ordnet diese Identität den richtigen Downstream-Anmeldeinformationen für jeden MCP-Server zu. Einzelne Entwickler berühren ein OAuth-Token niemals direkt.

Auf der Admin-Seite organisieren Sie Server in MCP-Servergruppen und weisen Sie den Zugriff nach Team oder Rolle zu. Ein Junior-Entwickler könnte GitHub-Zugriff nur zum Lesen erhalten. Ein leitender Ingenieur erhält vollen GitHub plus Schreibzugriff auf JIRA. Das Gateway setzt diese Grenzen auf Protokollebene durch — nicht durch Konfigurationsdateien des Honor-Systems.

Hier ist eine detaillierte Anleitung für Okta OAuth2-Authentifizierung einrichten mit MCP-Servern über das Gateway, einschließlich der Bereitstellung von Autorisierungsservern, der Bereichsverwaltung und der Konfiguration der Token-Aktualisierung.

Bewährte Methoden für die MCP-Authentifizierung in Cursor

• Übergeben Sie niemals Geheimnisse an mcp.json. Verwenden Sie die $ {env:VAR} -Referenzsyntax für Stdio-Server. Greifen Sie auf Remote-Servern nach OAuth. Wenn statische Header Ihre einzige Option sind, verweisen Sie auch in diesen auf Umgebungsvariablen.
• Bevorzugen Sie OAuth gegenüber statischen Tokens für alles, was entfernt ist. OAuth-Token laufen ab. Sie können sie eingrenzen. Sie können sie widerrufen. Statische Token tun nichts davon.
• Pinne deine mcp-remote-Version, wenn du darauf angewiesen bist. CVE-2025-6514 hat bewiesen, dass ein ungepatchter OAuth-Proxy Ihre gesamte Entwicklungsumgebung gefährden kann. Führen Sie npx -y mcp-remote @0 .1.16 oder höher aus — niemals @latest in der Produktion.
• Schränken Sie Token-Bereiche aggressiv ein. Wenn der Cursor Sie durch einen OAuth-Flow führt, gewähren Sie das Nötigste. Schreibgeschützt für die Codesuche. Schreibzugriff nur, wenn der Agent wirklich Probleme erstellen oder PRs zusammenführen muss.
• Überprüfe deine verbundenen Server regelmäßig. Gehe zu Cursoreinstellungen → Tools & MCP und überprüfe, was aktiv ist. Töte alles, was du nicht mehr benutzt. Jeder verbundene Server ist ein aktiver Anmeldeinformationen, der im Speicher gespeichert ist.
• Halten Sie den Cursor aktuell. Jede Version enthält Verbesserungen und Sicherheitspatches für die OAuth-Handhabung. Eine veraltete Cursor-Version bedeutet, dass veralteter Authentifizierungscode auf Ihrem Computer ausgeführt wird.

Fazit

Die MCP-Authentifizierung in Cursor umfasst ein breites Spektrum — von einem Klartext-API-Schlüssel in einer JSON-Datei bis hin zu einem vollständigen OAuth 2.1-Flow mit PKCE, dynamischer Registrierung und automatischer Token-Aktualisierung. Die Wahl der richtigen Methode hängt vom Bereitstellungsmodell des Servers ab und davon, wie ernst Sie Ihre Sicherheitslage nehmen.

Für die lokale Entwicklung verhindern Umgebungsvariablen in Kombination mit der $ {env:VAR} -Syntax, dass Anmeldeinformationen der Versionskontrolle entzogen werden. Bei Remotediensten entfernt OAuth die manuelle Tokenverwaltung vollständig aus der Gleichung. Und für Teams oder Unternehmen ein MCP Gateway wie True Foundry's zentralisiert die Speicherung von Anmeldeinformationen, erzwingt den rollenbasierten Zugriff und bietet Ihnen einen vollständigen Audit-Trail für jede MCP-Verbindung.

Erkunden Das MCP-Gateway von TrueFoundry oder eine Demo buchen um die zentralisierte MCP-Authentifizierung in Aktion zu sehen.

Häufig gestellte Fragen

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

Cursor bietet drei: Umgebungsvariablen, die in lokale stdio-Serverprozesse eingefügt werden, statische HTTP-Header (Bearer-Token oder API-Schlüssel) für Remote-Server und OAuth 2.1 mit PKCE für Remote-Server, auf denen die MCP-Autorisierungsspezifikation ausgeführt wird. OAuth-Unterstützung ist seit Cursor v1.0 verfügbar, das im Juni 2025 ausgeliefert wurde.

Wie funktioniert OAuth für MCP in Cursor?

Wenn Sie einen Remote-MCP-Server hinzufügen, der OAuth benötigt, folgt Cursor der MCP-Autorisierungsspezifikation. Es findet den Autorisierungsserver über Protected Resource Metadata (RFC 9728), registriert sich selbst als Client, öffnet Ihren Browser, damit Sie sich anmelden und Berechtigungen erteilen können, und tauscht dann mithilfe von PKCE den Autorisierungscode gegen Token aus. Der Cursor hält die Token sicher und aktualisiert sie von selbst, wenn sie bald ablaufen.

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

Wenn Sie rohe API-Schlüssel in mcp.json einfügen, werden Anmeldeinformationen im Klartext auf der Festplatte gespeichert. Wenn diese Datei der Versionskontrolle übergeben wird, ist der Schlüssel undicht. Tauschen Sie stattdessen die $ {env:variable_name} -Referenzsyntax ein — sie ruft zur Laufzeit Werte aus Ihrer Systemumgebung ab. Bevorzugen Sie für Remoteserver OAuth, das statische Anmeldeinformationen vollständig ausblendet.

Was war die mcp-remote-Schwachstelle?

CVE-2025-6514 war ein kritischer Command-Injection-Bug (CVSS 9.6) im mcp-remote-npm-Paket, der die Versionen 0.0.5 bis 0.1.15 betraf. JFrog Security Research entdeckte, dass das Paket die URLs der OAuth-Autorisierungsendpunkte ohne jegliche Säuberung an Systemhandler weiterleitete. Ein bösartiger MCP-Server könnte eine URL erstellen, die beliebige Betriebssystembefehle auf dem Computer des Entwicklers ausführt. Version 0.1.16 hat das Update ausgeliefert.

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

Mit einem MCP Gateway, das die gesamte Verwaltung der Anmeldeinformationen übernimmt. Das TrueFoundry-Gateway speichert und aktualisiert OAuth-Token pro Benutzer, ordnet Organisationsidentitäten nachgelagerten MCP-Anmeldeinformationen zu und setzt rollenbasierte Zugriffsrichtlinien durch. Entwickler melden sich einmal an und müssen sich nie wieder mit einzelnen MCP-Server-Tokens befassen.

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

Noch nicht, Stand Anfang 2026. Cursor stützt sich bei seinen OAuth-Flows immer noch auf die dynamische Client-Registrierung (DCR). In der MCP-Spezifikation vom November 2025 wurde CIMD als bevorzugte Registrierungsmethode eingeführt, aber Beiträge im Community-Forum vom Januar 2026 deuten darauf hin, dass die Funktion noch nicht ausgeliefert wurde. DCR funktioniert in der Zwischenzeit für die meisten OAuth-fähigen MCP-Server weiterhin einwandfrei.