MCP-Autorisierung: Nach der geltenden Spezifikation antworte zuerst »Wer bist du?«

Einleitung

MCP (Model Context Protocol) ist die Standardverdrahtung zwischen KI-Anwendungen und externen Tools: Ein MCP-Host (wie Claude Code, Claude Desktop oder VS Code) erzeugt einen Client pro MCP-Server, und Server stellen drei Primitive bereit — tools, resources, prompts. Dieser Beitrag untersucht sein Autorisierungsmodell nach der offiziellen geltenden MCP-Autorisierungsspezifikation (Version 2026-07-28; am 6. Oktober 2026 verifiziert, dass /specification/latest hierher weiterleitet). (Produktanalyse mit Stand vom 6. Oktober 2026.)[1]

[1] [2]

Autorisierung bleibt optional

Die geltende Spezifikation: Authorization is OPTIONAL. Implementierungen mit HTTP SHOULD dieser Spezifikation folgen; lokale Server mit STDIO SHOULD NOT diesem OAuth-Flow folgen, sondern Anmeldedaten aus der Umgebung beziehen. Beachten Sie: Das ist SHOULD NOT, nicht technisch unmöglich — ob lokal sicher ist, hängt von Prozessisolation und Anmeldedatenverwaltung ab, und die Spezifikation überlässt das den Implementierern.[2]

[2]

Drei Rollen

Die geltende Spezifikation führt einen Abschnitt »Roles« mit drei Parteien ein: Der geschützte MCP-Server ist der OAuth-2.1-Resource-Server; der MCP-Client ist der OAuth-2.1-Client, der geschützte Ressourcenanfragen im Namen eines Resource Owners stellt; der Authorization Server interagiert bei Bedarf mit dem Nutzer und stellt Access Tokens aus und kann gemeinsam mit dem Resource Server oder als separate Entität gehostet sein — seine Implementierungsdetails liegen außerhalb dieser Spezifikation. »Wer Tokens ausstellt« und »wer sie empfängt« sind formal getrennt.[2]

[2]

Resource- und Audience-Bindung

Die geltende Spezifikation verlangt von Clients, Resource Indicators nach RFC 8707 zu implementieren: Der resource-Parameter MUST sowohl in Authorization- als auch in Token-Requests enthalten sein und die kanonische URI des MCP-Servers identifizieren, für den das Token bestimmt ist; der Server als Resource Server MUST verifizieren, dass Access Tokens gezielt für ihn als intended audience ausgestellt wurden, nur Tokens akzeptieren, die von seinem eigenen Authorization Server für seine eigenen Ressourcen ausgestellt wurden, und MUST NOT irgendwelche anderen Tokens akzeptieren oder transitieren. Tokens sind an Ressourcen gebunden: ein Token, ein Ort.[2]

[2]

DCR obsolet

In der geltenden Spezifikation ist Dynamic Client Registration (DCR) obsolet und nur zur Abwärtskompatibilität erhalten; Authorization Server und MCP-Clients SHOULD OAuth Client ID Metadata Documents unterstützen. Vor Initiierung des Autorisierungsflows MUST Clients eine Client-ID über einen von drei Mechanismen erhalten — Client ID Metadata Documents, Vorregistrierung oder DCR — in der von der Spezifikation definierten Prioritätsreihenfolge.[2]

[2]

Scope-Challenges und Step-up

Die geltende Spezifikation detailliert die Behandlung unzureichender Rechte: Server MAY einen scope-Parameter im WWW-Authenticate-Header der 401-Antwort mitsenden, der die erforderlichen Berechtigungen weist; wird ein Token wegen unzureichenden Scopes abgelehnt, SHOULD der Server mit 403 und insufficient_scope antworten — beachten Sie, dass dies der Fall unzureichenden Scopes ist; ungültige oder abgelaufene Tokens erhalten weiterhin 401. Der Client re-autorisiert sich mit einer größeren Scope-Menge über den Step-up-Flow und wiederholt.[2]

Zwei verschiedene »Menschen« sind zu unterscheiden: Die Step-up-Reautorisierung läuft über den OAuth-Autorisierungsflow, den im Namen eines Nutzers handelnde Clients laut Spezifikation SHOULD versuchen — und dieser Flow selbst kann Nutzerinteraktion erfordern; das Autorisierungsprotokoll erlaubt und verlangt in manchen Fällen interaktive Autorisierung. Aber das ist nicht dasselbe wie »verpflichtende menschliche Freigabe für jeden Tool-Aufruf«. Ersteres ist ein Mechanismus innerhalb des Autorisierungsprotokolls, letzteres Host-Aufrufpolicy. Das ist nicht dasselbe.[2]

[2]

Der 401-Handshake

Wenn eine Autorisierung erforderlich ist und der Client sie noch nicht nachgewiesen hat, antwortet der Server mit HTTP 401, woraufhin der Client den OAuth-2.1-Flow initiiert; Tokens reisen im Authorization-Header, niemals im Query-String der URI (Anforderung aus Section 5 von OAuth 2.1, zitiert von der geltenden Spezifikation). Clients gleichen jeden zurückgegebenen iss exakt mit dem zuvor erfassten issuer ab; ein fehlender iss muss nur dann zur Ablehnung führen, wenn der Autorisierungsserver die Unterstützung dafür angibt (RFC 9207).[2]

[2]

Die Enterprise-Antwort

Die Enterprise-Erweiterung (unabhängig versioniert) macht den IdP der Organisation zum maßgeblichen Entscheider: Mitarbeitende melden sich einmal an, und der IdP entscheidet nach Organisationsrichtlinie, auf welche MCP-Server sie zugreifen dürfen; laut Dokumentation der Erweiterung erfolgt in Deployments, die die Erweiterung implementieren und unterstützen, der Widerruf einmal auf IdP-Ebene und wirkt sofort auf allen Clients. Keine praktische Prüfung von Implementierungen; es ist nicht garantiert, dass sich alle MCP-Deployments so verhalten. Individuelle Autorisierung ist für Verbraucher vernünftig; in Unternehmen erzeugt sie Reibung und Lücken.[3]

[3]

Kommentar

1. Das Protokoll standardisiert nur den Handshake, nicht die Policy. Der Abschnitt »Roles« stellt die Implementierung des Authorization Servers explizit außerhalb des Spezifikationsumfangs — MCP entscheidet nicht einmal, »wer Tokens ausstellt«. Das ist ein ehrliches Design: Bewerten Sie ein Deployment, schauen Sie auf die Seite des Authorization Servers, nicht auf das Kabel.

2. Die Obsoleszenz von DCR zeigt ein konvergierendes Protokoll. Der Wechsel von »alles dynamisch registrieren« zu »zuerst Identitätsmetadaten deklarieren« verlagert Vertrauen von der Laufzeitverhandlung zur Deklaration bei der Registrierung. Komfort weicht der Auditierbarkeit: die typische Trajektorie eines reifenden Protokolls.

3. »In wessen Namen« bleibt der Ursprung. Die geltende Spezifikation behält die Unterscheidung im Step-up-Abschnitt: »im Namen eines Nutzers handelnde Clients« vs. »client_credentials-Clients« folgen unterschiedlichen Flows [2]. Im Namen eines Nutzers zu handeln versus als die Anwendung selbst zu handeln impliziert völlig unterschiedliche Audit- und Widerrufslogik: Fragen Sie bei der Auswahl zuerst dies, dann nach Scopes.

4. Das Autorisierungsprotokoll ist nicht die Freigabe pro Aktion. Scope-Challenges und Step-up sind Berechtigungsmechanismen innerhalb des Protokolls, und Step-up kann Nutzerinteraktion umfassen; aber »verpflichtende menschliche Freigabe für jeden Tool-Aufruf« ist eine andere Sache und gehört zur Host-Policy. Beim Design einer Agenten-Publishing-Pipeline müssen Protokollschicht (»darf dieses Token verwendet werden«) und Policy-Schicht (»ist dieser Aufruf freigegeben«) getrennt sein — wie Entwurf, Review und Release-Signierung niemals dieselben Hände sein dürfen.

5. Vier Fragen für Praktiker (geltende Spezifikation). Wer ist der Authorization Server (mit dem Resource Server zusammen oder unabhängig)? Wird die Resource-/Audience-Bindung tatsächlich enforced? Wie sieht die Scope-Challenge-Strategie des Servers aus (wie wird 403 verwendet)? Welcher der drei Client-Registrierungsmechanismen wird verwendet? Wer nicht antworten kann, sollte noch keine Produktionsdaten verbinden.

[2]

Was noch nicht behauptet werden kann

Wie vollständig Hosts und Clients die geltende Spezifikation implementieren (nicht praktisch getestet);

Der tatsächliche Fortschritt der DCR-Obsoleszenz;

Die tatsächliche Sicherheitslage konkreter MCP-Server (laut deren eigener Dokumentation und Audits).