Remote MCP und OAuth-Autorisierung

Remote MCP und OAuth-Autorisierung

0:00 Ein Token, das überall gilt, ist kein Nachweis. Es ist ein Generalschlüssel mit Verfallsdatum. Dieser Gedanke trägt das ganze Modul, denn die Autorisierungsspezifikation von MCP dreht sich im Kern um eine einzige Frage: Für wen war dieses Token ausgestellt? Wer sie sauber beantwortet, hat die Mehrzahl der Angriffe aus Modul 14 geschlossen. Wer sie großzügig beantwortet, hat sie alle offen.

Remote MCP und OAuth-Autorisierung

0:25 Wir verlassen den lokalen Betrieb. Ein entfernter MCP-Server ist ein reguläres Stück Unternehmens-IT — mit allem, was dazugehört: Anmeldung, Berechtigungen, Netzgrenzen, Protokollierung. Die gute Nachricht ist, dass MCP dafür nichts Eigenes erfindet, sondern auf OAuth 2.1 aufsetzt. Die schlechte ist, dass es dabei ein paar Feinheiten gibt, die man kennen muss.

Wann ein lokaler Server genügt

0:49 Fangen wir mit der Entscheidung an, ob man den Schritt überhaupt gehen muss. Ein lokaler Server läuft als Unterprozess des Clients und holt seine Zugangsdaten aus der Umgebung. Die Autorisierungsspezifikation gilt für ihn ausdrücklich nicht — das ist kein Versäumnis, sondern Absicht: Der Prozess läuft ohnehin mit den Rechten des Nutzers, da wäre OAuth eine Fassade.

1:10 Ein entfernter Server ist dagegen ein eigenständiger Dienst über Streamable HTTP und braucht alles, was ein Dienst braucht. Vier Zeilen, und die Entscheidung fällt fast immer an der ersten. Die Fußzeile sagt es direkt: Sobald ein zweiter Mensch denselben Server braucht, ist die lokale Variante am Ende. Alles andere — Zugangsdaten, Betriebsaufwand, Datenzugriff — folgt daraus.

1:33 Es lohnt nicht, diese Entscheidung technisch zu diskutieren; sie ist eine Frage des Nutzerkreises, und die beantwortet der Fachbereich, nicht die Architektur. Hier zahlt sich die Schichtentrennung aus Modul 3 aus. Die Protokollsemantik ist auf beiden Transports identisch, die Fachlogik bleibt unverändert, der Transport wird getauscht.

1:54 Neu hinzu kommen Autorisierung, Betrieb und Telemetrie — das ist Arbeit, aber es ist keine Umschreibung. Und der vierte Punkt ist der, der die Sache angenehm macht: Der zustandslose Kern macht das Skalieren unkompliziert. Keine Sitzungsbindung, keine klebrigen Verbindungen. Der erste Punkt ist die verbreitetste Abkürzung und eine echte Sicherheitslücke: Ein lokaler Server wird fürs Team freigegeben, indem er auf allen Schnittstellen lauscht.

2:21 Dann ist er im Netz erreichbar, ohne Anmeldung, mit den Rechten des Entwicklers. Der dritte ist die Ausrede, die in vielen Unternehmen zieht: Der entfernte Betrieb startet ohne Autorisierung, weil es ja intern ist. Internes Netz ist seit fünfzehn Jahren kein Sicherheitsmerkmal mehr.

OAuth 2.1 als Autorisierungsgrundlage

2:37 Kommen wir zur Autorisierung selbst. MCP setzt auf Bewährtes und schärft an zwei Stellen nach. Die Rollenverteilung ist klassisch: Der MCP-Server ist Resource Server, der Client ist OAuth-Client, und der Autorisierungsserver ist eine eigene Instanz. Neu und verpflichtend ist, dass MCP-Server Protected Resource Metadata nach RFC 9728 bereitstellen müssen — damit ein Client überhaupt herausfindet, wer für die Anmeldung zuständig ist.

3:05 Das ist die Antwort auf eine Frage, die in frühen Versionen jeder anders gelöst hat. Drei Zeilen HTTP, und darin steckt der ganze Einstieg. Der Server antwortet mit einem Fehler, verweist auf seine Metadaten und nennt im Feld für den Berechtigungsumfang, was dieser Zugriff braucht. Das letzte ist der elegante Teil: Der Client muss nicht raten, welche Berechtigungen er anfragen soll, und er muss auch nicht vorsorglich alles anfragen.

3:32 Die Fußzeile sagt es — das führt ihn zum kleinsten passenden Umfang, und genau das will man. Zwei Punkte, die man kennen muss. Erstens: Der Client muss vor dem Einlösen des Codes prüfen, ob die Antwort tatsächlich von dem Autorisierungsserver kommt, den er sich gemerkt hat. Das ist die Abwehr gegen Mix-up-Angriffe, und die Spezifikation erklärt eigens, warum die übliche Absicherung dagegen nicht hilft.

3:56 Zweitens: Die dynamische Registrierung ist abgekündigt; empfohlen sind Client ID Metadata Documents, bei denen die Client-Kennung eine erreichbare Adresse ist. Der erste Punkt ist der folgenschwerste und kommt gleich im nächsten Kapitel ausführlich: Der Server prüft die Signatur, aber nicht den Empfänger. Der dritte ist ein Angriff, den viele nicht auf dem Schirm haben — der Client folgt der Metadaten-Adresse ohne Schutz vor internen Zielen.

4:21 Die Spezifikation beschreibt das als Server-Side Request Forgery und empfiehlt konkret, private Adressbereiche zu sperren und keinesfalls selbst zu parsen, weil Angreifer mit Kodierungstricks arbeiten.

Audience, Scopes und Token-Hygiene

4:32 Jetzt zum Kern des Moduls. Es geht um die Frage, für wen ein Token gilt. Zwei Pflichten, eine auf jeder Seite. Clients müssen Resource Indicators nach RFC 8707 umsetzen — ein Parameter in Autorisierungs- und Tokenanfrage, der die kanonische Adresse des Ziel-Servers nennt. Und Server müssen prüfen, dass ein Token für sie als Empfänger ausgestellt wurde. Beides zusammen macht aus einem Generalschlüssel einen Schlüssel für eine Tür.

5:00 Die Spezifikation formuliert das unmissverständlich: Server dürfen keine anderen Token annehmen und keine weiterleiten. Vier Felder, die zusammen das Thema abschließen. Empfänger prüfen — nur Token für diesen Server annehmen. Nichts weiterreichen — kein Token an nachgelagerte Systeme. Eng schneiden — Berechtigungen entlang der Werkzeugklassen aus Modul 7, also lesend, vorbereitend, verändernd. Und kurz halten — begrenzte Gültigkeit und Rotation.

5:30 Wenn Sie aus diesem Modul vier Sätze mitnehmen, dann diese. Das Weiterreichen von Token hat einen eigenen Namen und ein ausdrückliches Verbot. Die Spezifikation nennt drei Risiken. Erstens umgehen weitergereichte Token die Kontrollen des Servers — Rate Limits, Prüfungen, Protokollierung greifen nicht mehr. Zweitens protokolliert das Zielsystem eine falsche Herkunft, womit jede spätere Untersuchung ins Leere läuft.

5:55 Und drittens wird der Server damit zum Werkzeug für Datenabfluss, wenn jemand ein gestohlenes Token mitbringt. Der erste Punkt ist die konkrete Versuchung in unserem Beispiel: Der Server reicht das Token an das Kontenwerk durch, weil es dort zufällig passt. Der zweite ist der Entwurfsfehler, der alles zunichtemacht: Es gibt einen Berechtigungsumfang namens voll und sonst keinen.

6:18 Der dritte ist eine Verwechslung, die man häufig sieht: Der Umfang steht im Token und wird für ausreichend gehalten — die Spezifikation verlangt aber serverseitige Prüflogik, nicht bloß das Vorhandensein eines Anspruchs.

Transport und Durchsetzung

6:31 Bleibt die Frage, wie das Ganze im Netz durchgesetzt wird — und welche Rolle Zwischenstellen dabei spielen dürfen. Streamable HTTP spiegelt ausgewählte Felder in Header, damit Zwischenstellen routen und messen können, ohne den Nachrichtenkörper zu lesen: einen Header für die Methode, einen für den Namen des Werkzeugs oder der Ressource.

6:50 Und damit daraus keine Lücke wird, gibt es die Gegenprobe — weichen Header und Rumpf voneinander ab, muss der Server ablehnen. Sonst könnte jemand der Zwischenstelle etwas anderes erzählen als dem Server. Fünf Header, und der letzte Satz der Fußzeile ist der wichtige: Die Autorisierung gehört in jede einzelne HTTP-Anfrage.

7:09 Es gibt keine Sitzung, die sie trägt — das ist die Konsequenz aus der Zustandslosigkeit in Modul 4. Für die Implementierung heißt das: keine Anmeldung beim Verbindungsaufbau, kein Merken. Jeder Aufruf weist sich selbst aus, und jeder Aufruf wird einzeln geprüft. Ein Detail, das man leicht übersieht und das die Spezifikation eigens regelt: Wer nach Headern routet, muss deren Prüfung voraussetzen können.

7:35 Deshalb soll eine Zwischenstelle die Protokollversion mitprüfen — und bei älterer oder fehlender Version lieber ablehnen als den Headern vertrauen. Denn ältere Protokollversionen kannten die Header-Rumpf-Prüfung nicht. Ein Gateway, das das nicht beachtet, routet auf Angaben, die niemand validiert hat. Der erste Punkt ist genau dieser Fall in seiner gefährlichsten Ausprägung: Das Gateway entscheidet nach Header, der Server arbeitet nach Rumpf.

8:00 Der zweite ist ein Datenschutzthema, das wir in Modul 5 gestreift haben — sensible Parameter werden in Header gespiegelt und sind damit für Zwischenstellen sichtbar. Und der vierte ist der, über den wir in Modul 8 gesprochen haben und der hier im entfernten Betrieb erst richtig wirksam wird: Antworten je Nutzer werden öffentlich zwischenspeicherbar ausgeliefert.

Übung

8:20 Zum Abschluss entwerfen wir das Autorisierungskonzept — und suchen gezielt nach der einen Stelle. Der Entwurf ist Handwerk: Berechtigungen entlang der drei Werkzeugklassen, zugeordnet zu Rollen, dazu die Empfängerprüfung am Server. Und dann die eigentliche Aufgabe: Suchen Sie in Ihrem eigenen Entwurf die Stelle, an der ein Token weitergereicht würde.

8:41 Sie existiert fast immer, und sie wirkt beim Entwerfen völlig unauffällig. Getrennte Berechtigungen für Lesen, Vorbereiten und Ändern, drei Rollen mit begründeter Auswahl, die Empfängerprüfung beschrieben und verortet. Und dann die Passthrough-Stelle, ersetzt durch einen eigenen Berechtigungsnachweis. Der Hinweis verrät, wo Sie suchen sollten: Der Zugriff auf das Kontenwerk ist die Stelle, an der die Versuchung am größten ist — dort liegt ein Token, das dort funktionieren würde.

9:09 Der erste Punkt ist der häufigste Entwurfsfehler: Die Berechtigungen bilden die Werkzeugnamen ab statt die Wirkungsklassen. Dann haben Sie so viele Berechtigungen wie Werkzeuge und nichts gewonnen. Der zweite ist das Ergebnis, wenn man die Rollen nicht ernst nimmt: Am Ende bekommen alle drei dasselbe. Und der vierte ist die Falle, in die man beim Ersetzen des Passthrough läuft — der Ersatz ist derselbe Generalschlüssel, nur mit einem anderen Namen.