MCP-Autorisierung — OAuth 2.0 und stufenbasiertes API-Gating

Worum es geht

Die MCP-Spezifikationsrevision vom Juni 2025 lieferte erstmals ein formales Autorisierungsmodell für den Streamable-HTTP-Transport; dieses Modell wurde seither fortgeführt und verfeinert, zuletzt in der Revision vom 28. Juli 2026. Der stdio-Transport läuft in-process und vertraut der Prozessgrenze des Betriebssystems, weshalb er überhaupt keine externe Authentifizierungsschicht benötigt. Das HTTP-Modell baut auf OAuth 2.1 auf, dem konsolidierten und sicherheitsgehärteten Profil von OAuth 2.0, mit PKCE als Pflicht für jeden Client, dynamischer Client-Registrierung nach RFC 7591 und Resource Indicators nach RFC 8707. Ein Server stellt unter einem Well-Known-Pfad ein Discovery-Dokument bereit, das Clients an seinen Autorisierungsserver verweist; Clients durchlaufen den Authorization-Code-Flow mit PKCE und legen bei jeder JSON-RPC-Anfrage ein Bearer-Token vor. Resource Indicators binden ein Token an einen bestimmten MCP-Server — genau das verhindert, dass ein für einen Dienst ausgestelltes Token gegen einen anderen wiederverwendet wird.

Warum es zählt

• stdio benötigt keine Authentifizierung (Betriebssystemgrenze), aber jeder netzwerkexponierte MCP-Server muss OAuth 2.1 mit PKCE, dynamischer Client-Registrierung (RFC 7591) und Resource Indicators (RFC 8707) betreiben, um Tokens an einen Server zu binden.
• Tier-Gating übersetzt Identität in eine Tool-Teilmenge: Ein kostenloser Discover-Tier sieht bei find_firms nur öffentliche Felder, Buyer ergänzt vollständige Profile, Practice ergänzt search_news, Recruiter ergänzt Opportunity-Tools.
• Wird für einen Tool-Aufruf außerhalb des Tiers -32603 statt -32601 zurückgegeben, verrät das einem nicht authentifizierten Aufrufer die Existenz von Premium-Tools.

Kernpunkte

• OAuth 2.1 + PKCE für den HTTP-Transport (stdio ist in-process, OS-vertraut); die Spezifikationsrevision 2025-06-18 schreibt PKCE für öffentliche Clients vor.
• Discovery — /.well-known/oauth-protected-resource verweist Clients an den Autorisierungsserver; dynamische Client-Registrierung via RFC 7591.
• Bearer-Token im Authorization-Header bei jeder JSON-RPC-Anfrage; Resource Indicators (RFC 8707) binden Tokens an einen bestimmten MCP-Server.
• Tier-Gating-Schicht — übersetzt Token-Identität in eine Tool-Teilmenge; nicht berechtigte Aufrufe geben -32601 (method not found) zurück, nicht -32603 (Leak-Risiko).
• Stripe Meters + Rate-Limit-Worker — Nutzungsabrechnung, oberhalb von OAuth geschichtet (das Year-2-Modell der Plattform-Charta; §20.5 Cloudflare-Substrat).
• Autorisierung ist auf Protokollebene optional (Spezifikation 2026-07-28) — ein Server DARF über HTTP unauthentifiziert laufen; unterstützt er Autorisierung, MUSS er der Spezifikation folgen. stdio-Server SOLLTEN sie gar nicht erst aufsetzen.
• Die dynamische Client-Registrierung nach RFC 7591 ist inzwischen veraltet (Spezifikation 2026-07-28) — OAuth Client ID Metadata Documents (eine HTTPS-URL als client_id) sind der bevorzugte Registrierungsweg; DCR ist nur noch ein Rückwärtskompatibilitäts-Fallback.
• Schutz vor Mix-up-Angriffen — der Client muss den `iss`-Wert der Autorisierungsantwort gegen den erfassten Aussteller validieren (RFC 9207), eine seit der Revision 2025-06-18 hinzugekommene Anforderung.

Begriffe auf dieser Seite

OAuth 2.1 with PKCE

Das konsolidierte OAuth-Profil, das der MCP-HTTP-Transport übernimmt; PKCE (Proof Key for Code Exchange) ist für öffentliche Clients verpflichtend und ersetzt die Implicit- und Password-Grants, wodurch zwei langjährige Klassen von Token-Diebstahl-Schwachstellen entfallen.

Resource indicator (RFC 8707)

Eine OAuth-Erweiterung, die ein Access-Token an eine bestimmte geschützte Ressource (die MCP-Server-URL) bindet; ein für Server A ausgestelltes Token kann nicht gegen Server B wiederverwendet werden, selbst wenn beide denselben Autorisierungsserver teilen.

Tier-gating layer

Die serverseitige, oberhalb von OAuth geschichtete Prüfung, die eine authentifizierte Identität auf die Teilmenge an Tools abbildet, zu deren Aufruf der bezahlte Tier des Nutzers berechtigt; nicht berechtigte Aufrufe geben -32601 (method not found) zurück, niemals -32603 (was die Existenz kostenpflichtiger Tools verraten würde).

Dynamic client registration (RFC 7591)

Die OAuth-Erweiterung, die es einem MCP-Client erlaubt, sich beim Erstkontakt programmatisch beim Autorisierungsserver zu registrieren. Seit der MCP-Spezifikationsrevision vom 28. Juli 2026 ist dieser Mechanismus ausdrücklich veraltet und wird nur noch für Autorisierungsserver vorgehalten, die OAuth Client ID Metadata Documents noch nicht unterstützen.

OAuth Client ID Metadata Document

Der seit MCP-Spezifikation 2026-07-28 bevorzugte Registrierungsmechanismus: Die client_id des Clients ist selbst eine HTTPS-URL; der Autorisierungsserver ruft von dieser URL ein JSON-Metadatendokument ab, um Redirect-URIs und Eigenschaften des Clients zu erfahren — ohne separaten Registrierungs-Roundtrip (RFC 7591) oder manuelle Vorregistrierung.

OAuth 2.0 Protected Resource Metadata (RFC 9728)

Der Discovery-Mechanismus, den ein MCP-Server implementieren MUSS (Spezifikation 2026-07-28): ein Well-known-Dokument, das dem Client mitteilt, welcher Autorisierungsserver bzw. welche Autorisierungsserver ihn schützen und welche Scopes er unterstützt, damit der Client den Autorisierungsserver vor der Token-Anfrage lokalisieren kann.

Issuer validation (RFC 9207)

Eine dem MCP-Autorisierungsfluss hinzugefügte Verteidigung gegen Mix-up-Angriffe: Der Client erfasst den Aussteller-Identifikator des Autorisierungsservers, bevor er den Nutzer weiterleitet, und validiert dann den in der Autorisierungsantwort zurückgegebenen `iss`-Wert gegen diesen erfassten Wert, bevor er den Autorisierungscode überhaupt an einen Token-Endpunkt sendet.

Step-up authorization / insufficient_scope

Der formalisierte Laufzeit-Ablauf (Spezifikation 2026-07-28) für den Fall, dass die Scopes eines Tokens für eine Operation zu eng sind: Der Server liefert HTTP 403 mit `error="insufficient_scope"` und den erforderlichen Scopes zurück; der Client autorisiert sich erneut mit der Vereinigung bereits gewährter und neu benötigter Scopes, ohne bestehende Berechtigungen zu verlieren.

Quellen

1. MCP specification — Authorization
2. IETF OAuth 2.1 draft
3. RFC 7591 OAuth Dynamic Client Registration
4. Model Context Protocol — Authorization specification, revision 2026-07-28
5. Model Context Protocol — Client Registration (spec 2026-07-28)
6. Model Context Protocol — Authorization Security Considerations (spec 2026-07-28)
7. Model Context Protocol — Authorization Server Discovery (spec 2026-07-28)
8. Model Context Protocol — Specification changelog, 2026-07-28
9. IETF — OAuth 2.0 Protected Resource Metadata, RFC 9728
10. IETF — OAuth 2.0 Authorization Server Issuer Identification, RFC 9207
11. IETF — OAuth 2.0 Authorization Server Metadata, RFC 8414
12. RFC 8707 — Resource Indicators for OAuth 2.0 (binds a token to one MCP server)
13. RFC 7636 — Proof Key for Code Exchange (PKCE) by OAuth Public Clients (why PKCE is required for all clients)
14. RFC 6750 — OAuth 2.0 Bearer Token Usage (WWW-Authenticate challenge and 403 insufficient_scope used for step-up)
15. IETF OAuth WG — OAuth Client ID Metadata Document draft (HTTPS URL as client_id; MCP's preferred registration mechanism)
16. MCP specification 2026-07-28 — Security Best Practices (confused-deputy, token passthrough, session risks)
17. Cloudflare Agents docs — MCP authorization (vendor documentation, OAuth for remote MCP servers)