Security & Autorisierung: Vertrauensketten für MCP

Sicherheit beginnt vor der ersten MCP-Nachricht

Ein MCP-Server ist nicht nur ein Protokollendpunkt. Er kann lokal als Prozess mit Nutzerrechten laufen oder remote geschützte Daten und Seiteneffekte anbieten. Ein technisch gültiger Request beweist nur Interoperabilität. Er beweist weder die Identität des Endnutzers noch die Berechtigung für eine konkrete Ressource. Sicherheit entsteht aus einer Kette nachvollziehbarer Entscheidungen vor jedem geschützten Zugriff.

Dieses Modul konzentriert sich auf delegierte Autorisierung für HTTP-Server: geschützte Resource entdecken, Authorization Server zuordnen, Client sicher identifizieren, den Authorization Code Flow schützen und das Token am Ziel validieren. Host-Policy und serverseitige Fachautorisierung bleiben zusätzliche Grenzen. Ein vorhandenes oder korrekt signiertes Token ist nie automatisch eine pauschale Freigabe.

Das Threat Model beginnt beim falschen Empfänger

Die häufigsten OAuth-Schäden entstehen nicht durch fehlende Signaturprüfung, sondern durch falsche Bindung: Der Client holt ein Token beim falschen Aussteller, sendet es an den falschen Server, akzeptiert eine fremde Redirect-Rückgabe oder der Resource Server prüft seine Audience nicht. Jede Station muss deshalb dieselbe kanonische Zielresource meinen. Netzwerk- und Metadatenangaben sind Eingaben über eine Vertrauensgrenze und werden nicht blind verfolgt.

Protected Resource

Der tatsächlich angefragte MCP-Endpoint und seine verifizierten Metadaten

Authorization Server

Der für diese Resource zulässige Aussteller

Client

Die registrierte oder per Metadata Document beschriebene Anwendung

Endnutzer

Der Resource Owner, dessen delegierte Rechte begrenzt werden

Access Token

Kurzlebige Berechtigung für Audience, Scope und konkreten Einsatz

Ein Angreifer versucht, eine dieser Bindungen umzulenken: manipulierte Metadata zeigt in ein internes Netz, ein Code kehrt an eine offene Weiterleitung zurück, ein Token für calendar-api wird beim MCP-Server akzeptiert oder ein breiter Scope ersetzt die Objektprüfung. Entwerfe Kontrollen deshalb als zusammenhängende Invariante und teste falsche Kombinationen ausdrücklich. Positive Happy-Path-Tests beweisen keine Empfängerbindung.

Host-Policy und Resource-Server-Policy ergänzen sich

Der Host entscheidet, welchen Server und welche Capability er dem Nutzer und Modell anbietet, welche Scopes er anfordert und wann er Consent zeigt. Der Resource Server entscheidet unabhängig, ob das Token und die konkrete Fachaktion zulässig sind. Tool-Namen, Beschreibungen und Annotations helfen der Oberfläche, ersetzen aber keine der beiden Policies. Ein freundlicher Name kann eine breite Wirkung verbergen; ein Scope kann zu grob für die Objektentscheidung sein.

Metadata und Annotation

Orientierung für Oberfläche und Modell, aber keine selbst erteilte Berechtigung.

Host-Policy

Erlaubt oder verbietet Server, Tool, Parameterbereich und Interaktionszeitpunkt.

Serverseitige Autorisierung

Prüft Identität und Rechte erneut, bevor eine geschützte Wirkung erfolgt.

Annotations können UX und Risikoeinschätzung verbessern, etwa als Hinweis auf mögliche Seiteneffekte. Sie ändern aber weder die Produktpolicy noch die serverseitige Durchsetzung. Der Host hält Herkunft sichtbar, begrenzt Kontext und verlangt bei riskanten Vorgängen eine passende Freigabe außerhalb der Modellentscheidung.

Deny by default verbindet die Schichten: Der Host exponiert nur bekannte, lokal erlaubte Fähigkeiten. Der Server akzeptiert nur Tokens für seine Resource und prüft Tenant, Objekt und Aktion. Verändert der Server sein Tool-Schema oder fordert einen neuen Scope, wird die Entscheidung neu bewertet. Weder ein einmaliger Connect-Consent noch ein alter Token-Cache darf neue Wirkung automatisch erben. Audit korreliert Hostfreigabe, Autorisierungsflow und serverseitige Entscheidung, ohne Tokenwerte zu protokollieren.

HTTP-Autorisierung folgt einer Entdeckungskette

Die MCP-Autorisierung gilt für HTTP-basierte Transports. Der geschützte MCP-Server ist dabei OAuth Resource Server, der MCP-Client handelt im Namen des Resource Owners, und ein Authorization Server stellt Tokens aus. Für stdio beschreibt die MCP-Spezifikation diesen Flow ausdrücklich nicht; Credentials werden dort aus der lokalen Umgebung bezogen und müssen als eigene lokale Sicherheitsgrenze behandelt werden.

Die Discovery-Dokumente sind selbst Netzwerkdaten. Ein Client prüft daher HTTPS, URL-Schema, Ziel- und Netzwerkpolicy und verwirft Protected Resource Metadata, deren resource nicht zum tatsächlich angefragten MCP-Endpoint passt. Er folgt ihnen nicht blind in interne Netze oder in eine Shell. Die Discovery beantwortet, wo ein Authorization Server beschrieben ist; sie hebt keine Trust-Policy für einen bisher unbekannten Server auf.

Cache Metadaten nach dokumentierten Fristen, aber binde sie an die kanonische Resource und Netzwerkpolicy. Bei Redirects, DNS-Änderungen oder einem neuen Issuer ist erneute Trust-Prüfung nötig. Die Discovery-Implementierung begrenzt Schemes, Antwortgröße, Redirecttiefe und private Zielnetze entsprechend dem Produktkontext. Fehlende oder widersprüchliche Metadata führt zu einem kontrollierten Abbruch, nicht zu einer geratenen Standard-URL. Sicherheit verliert sonst genau an der Stelle, an der Automatisierung Bequemlichkeit schaffen sollte.

Resource Indicator und Audience binden Delegation

Ein OAuth Access Token ist keine allgemeine Nutzeridentität. Bei MCP enthält die Autorisierungs- und Token-Anfrage den resource-Parameter für die kanonische URI des angesprochenen MCP-Servers. So kann der Authorization Server ein Token für genau diese Ressource ausstellen. Der Resource Server prüft anschließend Signatur oder Introspection, Ablauf, Aussteller und insbesondere, ob er selbst die vorgesehene Audience ist.

Resource Indicator

Absicht des Clients beim Token-Bezug: für welchen MCP-Server wird Zugriff angefragt?

Audience-Validierung

Prüfung des Servers: wurde dieses Token für mich ausgestellt?

Token Passthrough

Ein fremdes Upstream-Token wird weitergereicht; das durchbricht die Empfängerbindung und ist im MCP-Flow unzulässig.

Ein Server darf weder Tokens für andere Ressourcen akzeptieren noch solche Tokens durch sich hindurchreichen. Das bleibt auch dann falsch, wenn derselbe Nutzer beide Systeme verwenden darf. Jeder geschützte Server muss seine eigene Autorisierungskette und seine eigene Durchsetzung besitzen.

Client-Registrierung wird ausgehandelt, nicht erfunden

Für unbekannte Gegenstellen können Client ID Metadata Documents die Client-Identität über ein HTTPS-Dokument beschreiben. Bei bestehender Beziehung gibt es vorregistrierte Client-Daten. Dynamic Client Registration gehört in der Revision 2026-07-28 zu den deprecated Features und ist keine Grundlage für neue Integrationen. Der Client wählt nur einen Weg, den Metadaten und Zugangspolitik des konkreten Authorization Servers unterstützen.

• Vorregistrierung: bekannte Client-Daten verwenden, wenn eine belastbare Beziehung besteht.
• Client ID Metadata Document: nur bei angekündigter Unterstützung; Dokument, Client-ID und Redirect-URIs konsistent validieren.
• Legacy DCR: ausschließlich in einer ausdrücklich abgegrenzten Kompatibilitätsschicht, nicht als moderner Default.
• Kein verfügbarer Weg: einen kontrollierten Konfigurations- oder Abbruchpfad zeigen statt Endpoints oder Client-IDs zu erraten.

Registrierung ist keine pauschale Vertrauenszusage. Besonders bei Proxies müssen Consent und Clientidentität pro delegierter Beziehung nachvollziehbar bleiben, damit ein statischer Upstream-Client nicht zur unbemerkten Stellvertretung für beliebige Downstream-Clients wird.

Ein Client ID Metadata Document wird über genau die HTTPS-Client-ID referenziert, deren Identität es beschreibt. Der Authorization Server prüft, dass dokumentierte Redirect-URIs und weitere Eigenschaften zur Anfrage passen; er darf nicht einfach ein fremdes Dokument unter beliebiger ID akzeptieren. Caching braucht Ablauf und erneute Validierung, weil eine geänderte Redirect-Liste sicherheitsrelevant ist. Für native oder lokal installierte Hosts gelten zusätzlich die Empfehlungen für öffentliche Clients: Ein eingebettetes Secret ist nicht geheim, daher tragen PKCE und exakte Redirect-Bindung den Flow.

PKCE und State schützen den Rückweg

Öffentliche Clients können ein Client Secret nicht zuverlässig geheim halten. Im Authorization-Code-Flow erzeugen sie daher pro Vorgang einen kryptografisch zufälligen code_verifier, senden davon die S256-abgeleitete Challenge zur Autorisierungsanfrage und verwenden den Verifier nur beim Token-Austausch. Ein abgefangener Authorization Code genügt ohne den Verifier nicht für den Token-Bezug.

State korreliert die Rückkehr mit der gestarteten Nutzeraktion und wird vor jeder weiteren Verarbeitung geprüft, kurzlebig gespeichert und genau einmal verbraucht. PKCE und State lösen verschiedene Probleme: PKCE bindet den Code-Austausch an den ursprünglichen Clientvorgang; State wehrt vertauschte, eingeschleuste oder alte Browser-Rückgaben ab. Beide Werte sind pro Flow gebunden.

Consent und Scopes delegieren nur eine konkrete Aufgabe

Scopes machen Berechtigungen prüfbar, sind aber keine Ersatzsprache für Geschäftsregeln. Der Server modelliert eine kleine, verständliche Scope-Oberfläche und prüft zusätzlich Ressource, Mandant, Objekt und Aktion. Der Client beginnt mit den für die aktuelle Aufgabe erforderlichen Rechten oder folgt einer präzisen Challenge. Für eine später benötigte privilegierte Aktion fordert er gezielt eine Stufenerhöhung an.

Initiale Delegation

Benötigt nur die minimale, für Discovery oder den aktuellen Workflow passende Berechtigung.

Step-up

Eine konkrete Operation scheitert mit unzureichendem Scope; der Client erklärt und fordert nur die notwendige Erweiterung an.

Serverdurchsetzung

Prüft Scope plus fachliche Berechtigung bei jeder Wirkung; ein Scope gewährt nicht automatisch jede Datenansicht.

Consent muss die delegierte Wirkung verständlich machen: welcher Client erhält für welchen Server welche Zugriffsklasse und warum jetzt. Ein breiter, unbegrenzt wiederverwendbarer Sammelscope senkt zwar Dialoge, vergrößert aber Schaden bei Tokenverlust und verschlechtert Auditierbarkeit.

Scope-Namen sollten eine stabile, verständliche Zugriffsklasse ausdrücken und nicht jede interne Rollenbezeichnung spiegeln. Zu wenige Scopes erzwingen breite Delegation; zu viele machen Consent unlesbar und Policy unwartbar. Beginne mit wenigen fachlichen Gruppen und behalte Objekt- und Tenantprüfung im Server. Der Host zeigt die zusätzliche Wirkung eines Step-ups, bindet ihn an den aktuellen Nutzerflow und übernimmt Ablehnung als normalen Ausgang. Ein erhaltenes Token wird nur im passenden Resource- und Principal-Cache wiederverwendet und nach Ablauf oder Widerruf entfernt.

Redirect-URIs sind feste Rückgabeadressen

Die Redirect-URI bestimmt, wohin Authorization Code und State zurückkehren. Authorization Server vergleichen sie exakt mit einer registrierten URI; Platzhalter, Host-Präfixe, offene Weiterleitungen oder ein nur ähnlicher Pfad erlauben Code-Diebstahl. Der Client registriert nur die Rückgabeadressen, die er tatsächlich kontrolliert, und validiert seine eigene Rückgabe ebenfalls gegen den gestarteten Flow.

• Exakter Vergleich: Scheme, Host, Port, Pfad und Query müssen zur vollständig registrierten URI passen.
• Jede Rückgabeadresse einzeln registrieren: eine zusätzliche URL ist keine Variante einer vorhandenen Registrierung.
• Keine offene Weiterleitung: ein Query-Parameter darf den Browser nicht zu einem beliebigen Ziel umleiten.
• Sichere Anzeige und Öffnung: URLs aus der Autorisierung werden geparst, auf erlaubte Schemes begrenzt und nicht über eine Shell gestartet.
• Lokale Sonderfälle bewusst behandeln: Loopback-Redirects sind eine andere Risikoklasse und benötigen klare Plattform- und Nutzerwarnungen.

Secrets dürfen keine MCP-Inhalte werden

Passwörter, API-Schlüssel, Refresh Tokens und andere langlebige Credentials gehören weder in Prompt-Argumente noch in Tool-Beschreibungen, Resource-Inhalte, Modellkontext, URLs oder unredigierte Logs. Ein einmal als MCP-Content zurückgegebenes Secret kann in Gesprächsverläufe, Telemetrie, Support-Exports oder nachgelagerte Modelle gelangen und ist kaum noch zuverlässig zurückzuholen.

Token und Secret speichern

Nur in einer dafür vorgesehenen, zugriffsbeschränkten Credential-Ablage; Zugriff ist an Identität und Zweck gebunden.

MCP-Request und Tool-Output

Nur Referenzen, Status oder redigierte Fehler; niemals den Secret-Wert transportieren.

Logging und Tracing

Sensitive Felder vor Persistenz maskieren; Zugriff, Aufbewahrung und Incident-Prozess bewusst festlegen.

Wenn ein Server eine geheime Eingabe benötigt, darf er sie nicht als scheinbar harmlosen Freitext über Modell oder Tool einfordern. Der sichere Weg ist eine passende Credential- oder Autorisierungsinteraktion außerhalb des Modellkontexts. Bei Verdacht auf Leak werden Credentials widerrufen oder rotiert und betroffene Logs nach dem Incident-Verfahren behandelt.

Eine Sicherheitsentscheidung bleibt über den gesamten Lifecycle wirksam

Die folgenden neun Checks sind absichtlich keine Checkliste für eine einzelne OAuth-Bibliothek. Sie trennen Provenance von Protokoll-Compliance, Hinweise von Berechtigungen, Discovery von Vertrauen und Tokenbesitz von zulässiger Delegation. Entscheidend ist jeweils, welche Grenze ein Vorschlag gerade auslässt.

• Serververtrauen: Herkunft und Ausführungsrechte vor der Verbindung begrenzen.
• Autorisierungsfluss: Resource, Audience, Registrierung, PKCE, State und Redirect konsistent verbinden.
• Datenhygiene: Consent, Scopes und Secrets so gestalten, dass ein einzelner Fehler begrenzten Schaden anrichtet.

Die Abnahme kombiniert Negativfälle: Resource Metadata nennt eine andere Resource, der Authorization Server wechselt unerwartet, State wird doppelt verwendet, die Redirect-URI unterscheidet sich nur im Pfad, ein Token besitzt gültige Signatur bei falscher Audience und ein Scope passt, aber die Objektberechtigung fehlt. Jeder Fall muss vor Fachwirkung geschlossen scheitern und eine stabile, nicht sensitive Fehlerklasse erzeugen. Danach werden Tokenwiderruf, Credential-Rotation und Cachebereinigung geprüft. So zeigt der Test nicht nur, dass ein Login funktioniert, sondern dass die Bindungen bei realistischen Verwechslungen halten. Protokolliere Entscheidung und Ursache, niemals Authorization Code, Verifier oder Tokenwert; sonst erzeugt gerade der Sicherheitsnachweis einen neuen Zugangspfad.