Authentifizierung ist die kritischste Sicherheitsebene für entfernte MCP-Server. Erfahren Sie, warum OAuth 2.1 mit OIDC obligatorisch ist, wie Token-Delegation den Confused-Deputy-Angriff verhindert und warum Token-Passthrough eines der gefährlichsten Muster in KI-Integrationen ist.
Authentifizierung ist der Torwächter, der bestimmt, ob die leistungsstarken Funktionen eines MCP-Servers legitimen Benutzern oder Angreifern zur Verfügung stehen. Wenn Sie es falsch machen, wird jede andere Sicherheitskontrolle irrelevant – ein nicht authentifizierter oder schlecht authentifizierter MCP-Server mit Zugriff auf E-Mails, Dateien und Datenbanken ist eine kritische Schwachstelle, unabhängig davon, wie gut Sie alles andere gehärtet haben.
Der Leitfaden des OWASP GenAI Security Project identifiziert Authentifizierung und Autorisierung als eine der acht zentralen Sicherheitsdomänen für MCP-Server, mit spezifischen Anforderungen, die über das hinausgehen, was die meisten Entwickler standardmäßig implementieren. Dieser Beitrag erklärt, warum diese Anforderungen existieren und wie man sie korrekt implementiert.
MCP-Server stehen vor einer komplexeren Authentifizierungslandschaft als traditionelle Dienste, da sie zwischen mehreren Hauptakteuren vermitteln:
Jede dieser Beziehungen erfordert eigene Authentifizierungs- und Autorisierungskontrollen. Eine Schwäche in einem Glied kann ausgenutzt werden, um die anderen zu umgehen.
Für entfernte MCP-Server – solche, auf die über ein Netzwerk zugegriffen wird und nicht über lokale STDIO- oder Unix-Sockets – ist der OWASP GenAI-Leitfaden eindeutig: OAuth 2.1 mit OIDC ist obligatorisch, nicht optional.
Diese Anforderung besteht, weil:
OAuth 2.1 bietet explizite Scope-Kontrolle. Jedes Zugriffstoken deklariert genau, welche Ressourcen und Aktionen es autorisiert. Ein MCP-Server kann zum Zeitpunkt des Tool-Aufrufs überprüfen, ob das präsentierte Token den spezifischen Scope hat, der für diese Aktion benötigt wird – nicht nur, dass der Benutzer authentifiziert ist, sondern dass er für diese spezifische Operation autorisiert ist.
OIDC bietet kryptografische Identität. OpenID Connect fügt Identitätsbestätigungen (das ID-Token) hinzu, die der MCP-Server überprüfen kann, ohne zum Identitätsanbieter zurückzukehren. Der Server validiert den iss (Aussteller), aud (Zielgruppe), exp (Ablauf) und die Signatur bei jeder Anfrage.
OAuth 2.1-Tokens sind von Natur aus kurzlebig. Die moderne OAuth-Spezifikation (die OAuth 2.0 Best Practices konsolidiert und ersetzt) betont kurzlebige Zugriffstokens, die regelmäßig erneuert werden müssen. Dies begrenzt das Schadensfenster, wenn ein Token kompromittiert wird.
Validieren Sie Tokens nicht nur bei der Sitzungseinrichtung. Validieren Sie bei jedem Tool-Aufruf:
def validate_token(token: str, required_scope: str) -> TokenClaims:
claims = jwt.decode(
token,
key=get_public_key(claims_preview['kid']),
algorithms=["RS256", "ES256"]
)
assert claims['iss'] == EXPECTED_ISSUER
assert EXPECTED_AUDIENCE in claims['aud']
assert claims['exp'] > time.time()
assert required_scope in claims['scope'].split()
return claims
Cachen Sie niemals Validierungsergebnisse über Anfragen hinweg. Ein Token, das zu Beginn der Sitzung gültig war, kann während der Sitzung widerrufen werden.
In Umgebungen, in denen sich MCP-Clients häufig ändern (z. B. verschiedene KI-Assistenten, die sich mit demselben Server verbinden), sind statische API-Schlüssel oder vorab geteilte Geheimnisse unzureichend. Verwenden Sie dynamische Client-Registrierung mit OAuth 2.1 oder OIDC, um die Client-Identität zum Zeitpunkt der Verbindung zu überprüfen. Allowlists, fest codierte Verbindungsrichtlinien oder gegenseitiges TLS (mTLS) sind für bekannte statische Beziehungen zwischen bestimmten Clients und Servern geeignet.
Starten Sie heute Ihre kostenlose Testversion und sehen Sie innerhalb weniger Tage Ergebnisse.
Der Confused Deputy ist eine klassische Autorisierungsschwachstelle mit einer besonders gefährlichen Manifestation in MCP-Architekturen. Der Angriff nutzt die Mehrdeutigkeit aus, mit wessen Autorität ein MCP-Server handelt.
Betrachten Sie dieses Szenario:
Wenn Alice den KI-Assistenten bittet, “meinen Projektordner zusammenzufassen”, verwendet der Server Alices Token, um auf ihre Dateien zuzugreifen – korrektes Verhalten. Aber wenn ein Angreifer den Server dazu verleitet, eine Anfrage mit seinen eigenen Dienstanmeldeinformationen zu stellen (vielleicht durch einen Tool-Poisoning-Angriff oder indirekte Prompt-Injection), werden die erhöhten Berechtigungen des Servers verwendet, um auf Dateien zuzugreifen, für die Alice nicht autorisiert ist.
Der Server ist der “confused deputy” – er wurde dazu verleitet, seine Autorität im Namen von jemandem zu verwenden, der diese Autorität nicht hat, und fungiert als Proxy für Privilege Escalation.
Viele MCP-Implementierungen leiten das Token des Clients aus Gründen der Einfachheit an nachgelagerte APIs weiter. Dies erscheint intuitiv – das Token des Benutzers repräsentiert die Berechtigungen des Benutzers, also gewährleistet seine Verwendung für alle nachgelagerten Aufrufe die korrekte Zugriffskontrolle.
Das Problem: Nachgelagerte APIs, die den MCP-Server als vertrauenswürdigen Vermittler erkennen, können Anfragen auf der Identitätsebene des Servers gewähren, nicht auf der Ebene des weitergeleiteten Benutzer-Tokens. Und wenn der MCP-Server jemals auf eigene Initiative handelt – durch KI-Entscheidungsfindung, die der Benutzer nicht explizit angefordert hat – kann er seine eigenen Anmeldeinformationen anstelle des Benutzer-Tokens verwenden.
Das Weiterleiten von Benutzer-Tokens führt auch zu:
Anstatt Client-Tokens weiterzuleiten, sollte der MCP-Server seine eigenen Tokens für den Zugriff auf nachgelagerte Dienste über den OAuth-On-Behalf-Of (OBO)-Flow erhalten:
Benutzer authentifiziert sich beim MCP-Client → Client erhält Benutzerzugriffstoken
MCP-Client präsentiert Benutzer-Token dem MCP-Server
MCP-Server tauscht Benutzer-Token gegen ein Server-Token über OBO-Flow aus:
POST /token
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<user_access_token>
scope=<minimum_required_scope>
MCP-Server verwendet sein eigenes OBO-Token für nachgelagerte Aufrufe
Das OBO-Token:
Der OWASP GenAI-Leitfaden gibt eine spezifische Empfehlung: Stellen Sie Zugriffstokens mit Lebensdauern aus, die in Minuten gemessen werden, nicht in Stunden. Dies gilt sowohl für die Tokens, die der MCP-Server von Clients akzeptiert, als auch für die Tokens, die er für den Zugriff auf nachgelagerte Dienste erhält.
Ein gestohlenes Zugriffstoken ist für seine gesamte Lebensdauer gültig, unabhängig davon, ob sich der legitime Benutzer abgemeldet, sein Passwort geändert oder seine Sitzung widerrufen hat. Ein 24-Stunden-Token, das zu Beginn einer Sitzung gestohlen wird, gibt einem Angreifer 24 Stunden dauerhaften Zugriff. Ein 5-Minuten-Token, das während der Sitzung gestohlen wird, gibt maximal 5 Minuten.
Kurzlebige Tokens erzwingen auch regelmäßige Neuauthentifizierungsereignisse, die Gelegenheiten bieten:
Jedes Token sollte nur die Scopes enthalten, die für die spezifische Operation erforderlich sind. Stellen Sie kein Token mit read:files write:files delete:files Scope aus, wenn der aktuelle Tool-Aufruf nur read:files benötigt. Dies begrenzt den Schaden, wenn das Token abgefangen wird oder das Modell zu unerwarteten Tool-Aufrufen manipuliert wird.
def get_tool_token(user_id: str, tool_name: str) -> str:
# Tool auf minimale erforderliche Scopes abbilden
required_scopes = TOOL_SCOPE_MAP[tool_name]
return oauth_client.get_token(
subject=user_id,
scopes=required_scopes,
lifetime_seconds=300 # 5 Minuten Lebensdauer
)
Erhalten Sie die neuesten Tipps, Trends und Angebote kostenlos.
Ein häufiger Fehler ist die Verwendung von Sitzungs-IDs als Autorisierungs-Proxys: Wenn eine Anfrage eine gültige Sitzungs-ID trägt, nimmt der Server an, dass sie autorisiert ist. Dies vermischt Zustandsverwaltung mit Identitätsüberprüfung.
Das korrekte Modell: Sitzungs-IDs verwalten den Konversationszustand. Die Autorisierung wird bei jeder Anfrage unabhängig überprüft, indem die Claims des OAuth-Tokens validiert werden. Selbst eine Anfrage mit einer gültigen Sitzungs-ID muss ein gültiges, nicht abgelaufenes, ordnungsgemäß begrenztes OAuth-Token präsentieren, bevor ein Tool-Aufruf erlaubt wird.
Dies ist wichtig, weil Sitzungs-IDs auf Arten gestohlen, erraten oder wiedergegeben werden können, die bei OAuth-Tokens – die kryptografische Integritätsgarantien tragen – nicht möglich sind.
Anstatt Autorisierungsprüfungen zu implementieren, die über einzelne Tool-Handler verstreut sind, empfiehlt der OWASP GenAI-Leitfaden ein zentralisiertes Richtlinien-Gateway, das:
Zentralisierung stellt sicher, dass Richtlinien konsistent über alle Tools und Agenten hinweg angewendet werden. Eine toolspezifische Autorisierungsprüfung kann während der Entwicklung vergessen oder umgangen werden; eine Gateway-Prüfung nicht.
Für entfernte MCP-Server ist die minimale Sicherheitsschwelle für Authentifizierung:
OAuth 2.1 ist für entfernte MCP-Server erforderlich, da es delegierte Autorisierung mit expliziter Scope-Kontrolle, kurzlebigen Tokens, kryptografischer Verifizierung und standardisierten Identitätsbestätigungen (über OIDC) bietet. Einfachere Methoden wie API-Schlüssel oder Sitzungscookies verfügen nicht über die Scope-Granularität, die für die Implementierung von Zugriff mit minimalen Berechtigungen erforderlich ist, bieten keine kryptografischen Identitätsgarantien und sind schwer granular zu widerrufen, wenn eine Sitzung endet.
Der Confused Deputy ist ein Privilege-Escalation-Angriff, bei dem der MCP-Server dazu verleitet wird, seine eigenen (höheren) Berechtigungen zu verwenden, um Aktionen auszuführen, für die der anfragende Benutzer nicht autorisiert ist. Es tritt auf, wenn Token-Passthrough verwendet wird – der Server leitet das Token eines Benutzers an nachgelagerte APIs weiter, die dem Benutzer möglicherweise aufgrund des vertrauenswürdigen Status des Servers Zugriff gewähren, den er nicht haben sollte. Die Lösung besteht darin, On-Behalf-Of-Token-Flows zu verwenden, bei denen Tokens explizit für den spezifischen Zugriffsbereich des MCP-Servers ausgestellt werden.
Token-Passthrough bedeutet, dass der MCP-Server das Authentifizierungstoken des Clients direkt an nachgelagerte APIs weiterleitet, anstatt seine eigenen serverausgestellten Anmeldeinformationen zu verwenden. Dies ist gefährlich, weil: (1) es Audit-Trails unterbricht – nachgelagerte Systeme sehen das Benutzer-Token, nicht den MCP-Server, was es unmöglich macht, Aktionen dem Server zuzuordnen; (2) es die eigenen Zugriffsrichtlinien des MCP-Servers umgeht; (3) es eine Confused-Deputy-Schwachstelle erzeugt, wenn die nachgelagerte API der Identität des MCP-Servers mehr vertraut als der des Benutzers; und (4) wenn der MCP-Server kompromittiert wird, erhält der Angreifer Zugriff auf weitergeleitete Benutzer-Tokens für alle verbundenen nachgelagerten Dienste.
Der OWASP GenAI-Leitfaden empfiehlt Tokens mit Lebensdauern, die in Minuten gemessen werden, nicht in Stunden oder Tagen. Kürzere Token-Lebensdauern begrenzen das Ausbeutungsfenster, wenn ein Token gestohlen oder eine Sitzung gekapert wird. Jeder Tool-Aufruf sollte die Signatur, Zielgruppe und Ablaufzeit des Tokens erneut validieren – nicht auf der zwischengespeicherten Validierung vom Sitzungsstart basieren.
Arshia ist eine AI Workflow Engineerin bei FlowHunt. Mit einem Hintergrund in Informatik und einer Leidenschaft für KI spezialisiert sie sich darauf, effiziente Arbeitsabläufe zu entwickeln, die KI-Tools in alltägliche Aufgaben integrieren und so Produktivität und Kreativität steigern.
Unser Sicherheitsteam bewertet MCP-Authentifizierungskonfigurationen, Token-Handling und Autorisierungsflüsse anhand der OWASP GenAI-Standards. Identifizieren Sie Lücken, bevor es Angreifer tun.
Das OWASP GenAI Security Project definiert einen Mindeststandard in fünf Kategorien für die sichere Bereitstellung von MCP-Servern. Verwenden Sie diese Checklis...
MCP-Server stellen eine einzigartige Angriffsfläche dar, die traditionelle API-Risiken mit KI-spezifischen Bedrohungen kombiniert. Lernen Sie die 6 kritischen S...
Der Authenticator App MCP Server ermöglicht es KI-Agenten, sicher auf 2FA-Codes und Passwörter zuzugreifen, automatisierte Anmeldeprozesse sowie die Verwaltung ...