MCP- und Agenten-Sicherheit

MCP und OAuth: den Vertrauensanker absichern

Von CyberSec42 Research · Stand 2026

Den OAuth-Vertrauensanker in MCP abzusichern heißt, vier Dinge serverseitig zu pinnen und zu prüfen: den Authorization-Server, die Herkunft der Protected-Resource-Metadata, den angefragten Scope und die Audience des Tokens. MCP hat OAuth 2.1 als Autorisierungsschicht übernommen und damit eine ganze Klasse von Trust-Root-Fehlern geerbt. Diese Klasse hat die höchste Hebelwirkung aller MCP-Risiken. Der Grund: ein einziger Bibliotheksdefekt schlägt an jeden abhängigen Server durch.

Kurz gefasst. Vier Invarianten sichern den OAuth-Vertrauensanker:

Den Origin des Authorization-Servers serverseitig pinnen oder allowlisten, statt ihn aus einer client-beeinflussbaren Quelle zu übernehmen.
Einen resource_metadata-Zeiger nur ehren, wenn sein Origin dem Resource-Origin gleicht (RFC 9728).
Den angefragten Scope mit dem Entitlement des Clients schneiden, deny by default, nie wörtlich gewähren.
Die Token-Audience (aud) prüfen, damit ein Token nur beim vorgesehenen Empfänger gilt.

Warum OAuth in MCP zum Angriffsziel wird

OAuth 2.1 regelt in MCP, welcher Client mit welchen Rechten auf einen Resource-Server zugreifen darf. Der Vertrauensanker ist die Frage, wem der Client glaubt, wenn er erfährt, wohin er sich zur Autorisierung wenden soll. Genau hier liegt das Problem: der Zeiger auf den Authorization-Server und die Resource-Metadaten stammt oft aus einem server-kontrollierten WWW-Authenticate-Header. Übernimmt der Client oder Server diesen Zeiger, ohne Origin und Issuer zu pinnen, kann ein bösartiger oder zwischengeschalteter Resource-Server den Grant auf eigene Infrastruktur umlenken, das ausgestellte Token ernten oder einen zu breiten Scope in die Consent injizieren.

Das macht diese Klasse so heikel: die verwundbare Stelle sitzt nicht in einem einzelnen Server, sondern in den geteilten Bibliotheken und SDKs darunter. Deshalb ist die Angriffsfront von einzelnen Servern zu diesen Bibliotheken gewandert. Ein Defekt dort wird von jedem abhängigen Server geerbt, ohne dass dessen Betreiber einen eigenen Fehler gemacht hat.

Der Zeiger auf den Authorization-Server kommt oft vom Resource-Server. Ohne Origin-Pinning lenkt ein bösartiger Server den Grant um.

Die vier Prüfpunkte im Detail

1. Authorization-Server-Origin pinnen

Der Client darf den Authorization-Server nicht blind aus einem Wert übernehmen, den der Resource-Server beeinflusst. Der Origin des Authorization-Servers gehört serverseitig gepinnt oder auf eine feste Allowlist gesetzt. Übernimmt der Client stattdessen eine beliebige authorization_server_url, kann ein Angreifer den gesamten Token-Fluss auf eigene Infrastruktur umleiten. Das ist ein klassischer Confused Deputy: der Client händigt im Vertrauen auf eine unverifizierte Herkunft das Resource-Token aus.

2. PRM-Origin gegen den Resource-Origin prüfen (RFC 9728)

RFC 9728 beschreibt, wie ein Client die Protected-Resource-Metadata eines Resource-Servers findet. Die Sicherheitsregel dabei: ein resource_metadata-Zeiger wird nur geehrt, wenn sein Origin dem Origin des Resource-Servers gleicht. Fehlt diese Same-Origin-Prüfung, kann ein Server auf fremde Metadaten zeigen und den Client an einen untergeschobenen Authorization-Server verweisen. Die Prüfung muss echte Origin-Gleichheit sein, also Scheme, Host und Port vergleichen, nicht ein loser Präfix-Check.

3. Scope mit dem Entitlement schneiden

Ein Client soll nur den Scope erhalten, auf den er tatsächlich Anspruch hat. Wird der in der Anfrage genannte Scope wörtlich in die Consent übernommen, kann ein Angreifer einen zu breiten Scope injizieren und sich Rechte verschaffen, die weit über den Anwendungsfall hinausgehen. Richtig ist die Schnittmenge: der gewährte Scope ist der angefragte Scope geschnitten mit dem Entitlement des Clients, deny by default. Das begrenzt den Schaden, selbst wenn ein Teil des Flusses manipuliert wurde.

4. Token-Audience prüfen

Ein Access-Token trägt eine Audience, die den vorgesehenen Empfänger benennt. Wird die aud-Claim nicht validiert, akzeptiert ein Resource-Server ein Token, das für einen anderen Dienst ausgestellt wurde. Die Prüfung der Audience stellt sicher, dass ein an einer Stelle erbeutetes Token nicht an einer anderen wiederverwendet werden kann. Zusammen mit dem geschnittenen Scope begrenzt das die laterale Bewegung eines Angreifers erheblich.

Warum diese Klasse Reviews so oft entgeht

Der Vertrauensanker liegt zwischen den Komponenten, nicht in einer einzelnen. Ein Review, das nur den Server-Code liest, sieht den korrekten Handler und übersieht, dass die Herkunft des Autorisierungs-Zeigers nie gepinnt wurde. Erschwerend kommt hinzu, dass die eigentliche Schwäche häufig in einer geteilten Bibliothek sitzt, die viele Server gemeinsam nutzen. Wer nur das eigene Repository prüft, findet den Fehler nicht, obwohl der eigene Server ihn erbt. Belastbar wird die Prüfung erst, wenn sie den Fluss über die Grenzen hinweg betrachtet und jeden der vier Prüfpunkte gegen eine definierte Invariante testet.

Hält Ihr OAuth-Vertrauensanker?

In einem kostenlosen Erstgespräch prüfen wir die vier Prüfpunkte an Ihrem MCP-Server und benennen, ob die Herkunft von Authorization-Server und Metadaten belegbar gepinnt ist. Jeder Befund kommt mit einem Proof of Concept, nicht mit einer Vermutung.

Erstgespräch anfragen

CyberSec42 ist eine unabhängige technische Sicherheitsprüfung, keine akkreditierte Zertifizierungsstelle.

Häufige Fragen

Warum nutzt MCP überhaupt OAuth?

MCP hat OAuth 2.1 als Autorisierungsschicht übernommen, um zu regeln, welcher Client mit welchen Rechten auf einen Resource-Server zugreifen darf. Damit erbt MCP aber auch die Trust-Root-Fehler von OAuth, wenn Herkunft und Scope nicht sauber gepinnt und geschnitten werden.

Was ist der OAuth-Vertrauensanker in MCP?

Der Vertrauensanker ist die Frage, wem der Client glaubt, wenn er erfährt, wohin er sich zur Autorisierung wenden soll. Der Zeiger auf Authorization-Server und Resource-Metadaten stammt oft aus einem server-kontrollierten Header. Wird er ungeprüft übernommen, kann ein Angreifer den Token-Fluss umlenken.

Was regelt RFC 9728 für MCP?

RFC 9728 beschreibt, wie ein Client die Protected-Resource-Metadata eines Resource-Servers findet. Die Sicherheitsregel: ein resource_metadata-Zeiger wird nur geehrt, wenn sein Origin dem Origin des Resource-Servers gleicht. Diese Same-Origin-Prüfung verhindert, dass ein Server auf fremde Metadaten verweist.

Warum ist diese Klasse die mit der höchsten Hebelwirkung?

Weil die Schwäche oft in den geteilten Bibliotheken und SDKs unter den Servern sitzt. Ein einziger Defekt dort wird von jedem abhängigen Server geerbt, ohne dass dessen Betreiber einen eigenen Fehler gemacht hat. Deshalb ist die Angriffsfront von einzelnen Servern zu den Bibliotheken gewandert.

Reicht es, die Audience zu prüfen?

Nein. Die Audience-Prüfung ist einer von vier Prüfpunkten. Ohne gepinnten Authorization-Server-Origin, Same-Origin-Prüfung der Metadaten und geschnittenen Scope bleibt der Vertrauensanker angreifbar. Die vier Invarianten wirken zusammen und sollten alle durchgesetzt werden.