Enterprise MCP Authorization Architecture: eine Multi-Tenant-Referenzarchitektur

Die Model-Context-Protocol-Spec sagt endlich etwas Konkretes zur Autorisierung: OAuth 2.1 nutzen, jedes Token per Resource Indicators an eine bestimmte Audience binden und niemals ein Client-Token an eine Downstream-API durchreichen. Die Anforderungen sind echt. Das Problem ist, dass sie über die Core-Spec, ein Security-Best-Practices-Dokument und ein halbes Dutzend IETF-RFCs verstreut sind, und fast jede Seite, die für diese Begriffe rankt, eine Security-Vendor-Checkliste ist, die beim Single-Server-Fall aufhört.

Das hier ist das Referenzdesign, das wir nutzen, wenn ein Kunde einen MCP-Server braucht, der mehr als einen Mandanten bedient, an einen Enterprise Identity Provider andockt und ein Procurement-Security-Review übersteht. Es ist herstellerneutral, wurde am 2. September 2026 gegen die Spec-Revision 2026-07-28 geprüft und zeichnet die komplette Trust Boundary vom Identity Provider bis zur mandantengetrennten Datenebene. Geschrieben aus Wavects Arbeit an KI-Produkten und Security-Hardening.

Diese Seite implementiert die MCP-Authorization-Ebene. Wenn du noch klärst, ob MCP selbst die Grenze sein kann, starte mit warum MCP keine Sicherheitsgrenze ist und Data-Level Access Control die Lücke schließt.

Wer verantwortet was: der MCP-Server ist Resource Server, kein Authorization Server

Der häufigste Fehler ist, den MCP-Server als eigenes Login-System zu bauen. Ist er nicht. Nach der aktuellen Spec ist der MCP-Server ein OAuth-2.1-Resource-Server. Seine Aufgabe ist es, Tokens zu validieren, nicht sie auszustellen. Ein separater Authorization Server, im Unternehmen also dein Identity Provider (Entra ID, Okta, Auth0, Keycloak, Ping), interagiert mit dem Nutzer und stellt Access Tokens aus.

Diese Trennung ist neu. Die erste Authorization-Spec (2025-03-26) erwartete, dass der MCP-Server beides ist, Authorization Server und Resource Server. Die Revision 2025-06-18 hat die Rollen über Pull Request 284 getrennt, wodurch sich Enterprise Identity Provider sauber in die Architektur einfügen. Der Authorization Server darf weiter beim Resource Server liegen, aber die vorgeschriebene Aufgabe des MCP-Servers ist Token-Validierung. Wenn du dieses Rollenmodell richtig setzt, fällt alles Weitere an seinen Platz. Setzt du es falsch, baust du Identity schlecht nach.

Was verlangt die aktuelle Spec eigentlich?

Zwei Vorbemerkungen. Erstens ist Autorisierung in MCP optional und für HTTP-basierte Transporte definiert. Ein Server mit STDIO sollte dieser Authorization-Spec nicht folgen; er zieht Credentials aus der Umgebung. Zweitens ist OAuth 2.1 weiterhin ein IETF-Draft, kein veröffentlichtes RFC, also zitiere keine RFC-Nummer dafür. Hier die Standard-Oberfläche für die Revision 2026-07-28.

Die Revision 2026-07-28 stuft Dynamic Client Registration zugunsten von Client ID Metadata Documents formell als veraltet ein, bindet gespeicherte Client Credentials an den Issuer des ausstellenden Authorization Servers und ergänzt die Issuer-Validierung der Authorization Response nach RFC 9207. PKCE bleibt verpflichtend: Clients müssen code_challenge_methods_supported vorab prüfen und, wenn technisch möglich, S256 verwenden.

Wie läuft der Autorisierungs-Flow von Anfang bis Ende?

Der ganze Handshake ist ein Discovery-Schritt gefolgt von einem Standard-Authorization-Code-Flow. Der Client trifft den Server ohne Token, bekommt gesagt, wo er sich authentifizieren soll, authentifiziert sich und kommt mit einem Token zurück, das für genau diesen Server ausgestellt ist.

Zwei Pflichtdetails stecken in diesem Diagramm. Der Server muss RFC-9728-Protected-Resource-Metadata über einen WWW-Authenticate-Header bei 401 Unauthorized oder unter einer Well-known-URI bereitstellen. Clients müssen beide Mechanismen unterstützen, die Header-URL nutzen, falls vorhanden, und sonst zuerst die endpunktspezifische und dann die Well-known-URI am Root prüfen. Bei Authorization- und Token-Requests muss der Client einen resource-Parameter mit der kanonischen URI des MCP-Servers senden, unabhängig davon, ob der Authorization Server Unterstützung ausweist.

Warum ist Token-Passthrough verboten, und wie validierst du Audience?

Das ist das Sicherheitsherz der Spec, und hier scheitern die meisten selbstgebauten Server. Die Regel ist eindeutig: Der MCP-Server muss validieren, dass jedes Access Token für ihn als beabsichtigte Audience ausgestellt wurde, und alles andere ablehnen. Er darf kein Token akzeptieren, das für einen anderen Dienst geprägt wurde, und er darf das empfangene Token nicht an eine Downstream-API weiterreichen. Genau dieses Anti-Pattern ist Token-Passthrough, und die Spec verbietet es klar.

Der Grund ist das Confused-Deputy-Problem. Wenn dein Server Tokens akzeptiert und weiterreicht, die er nicht geprüft hat, wird ein für einen Dienst geleaktes oder ausgestelltes Token zum Generalschlüssel für einen anderen, Rate Limits auf Audience-Basis werden umgangen und der Downstream-Audit-Trail zeigt die falsche Identität. Audience-Validierung ist ein Claim-Check, und er ist die Linie zwischen einem Resource Server und einer Haftung.

on every tool call:
  token = bearer_from_authorization_header()   # every request is self-contained
  claims = verify_signature(token, jwks_of(trusted_issuer))
  assert claims.iss == expected_issuer          # pinned per tenant
  assert this_server_uri in claims.aud          # RFC 8707 audience
  assert not expired(claims) and not before(claims)
  assert required_scope_for(tool) in claims.scope
  tenant = claims["tenant"] or claims["org_id"]
  enforce_tenant(tenant)                         # every query, every secret

Der Core 2026-07-28 hat den Protokoll-Handshake und Mcp-Session-Id entfernt. Jeder Request ist in sich abgeschlossen, und die Authorization-Spec verlangt das Bearer Token bei jedem HTTP-Request. Der Pseudocode nimmt JWT Access Tokens an, weil dieses Referenzdesign verifizierte Claims nutzt; MCP schreibt JWT nicht vor. Bei opaken Tokens musst du gleichwertigen, verifizierten Issuer-, Audience-, Scope- und Mandantenkontext per Introspection oder über ein vertrauenswürdiges Gateway beziehen.

Wie erreicht der Server Downstream-APIs, ohne das Token zu leaken?

Wenn der MCP-Server eine Downstream-API aufrufen muss, agiert er dieser API gegenüber als OAuth-Client und nutzt ein separates Token, das für diese API ausgestellt wurde. Die Spec sagt dir, was du nicht tun sollst (das eingehende Token nicht durchreichen), überlässt das Wie aber dem Ökosystem. Eine standardisierte Option ist Token Exchange nach RFC 8693: Der Server tauscht das eingehende Token, dessen Audience der MCP-Server ist, gegen ein neues Token, dessen Audience die Downstream-API ist.

Der Server spielt hier eine Doppelrolle: Resource Server zum Client, OAuth-Client zur API. Bevorzuge Delegation vor Impersonation, damit der ursprüngliche Nutzer im sub-Claim bleibt und die handelnde Kette im act-Claim festgehalten wird, was deinen Audit-Trail über den Hop hinweg ehrlich hält. Token Exchange und On-Behalf-of-Flows liegen außerhalb der Core-MCP-Spec, also behandle sie als Aufgabe des Identity Providers oder Gateways, nicht als MCP-Anforderung.

Wie sieht die Multi-Tenant-Referenzarchitektur aus?

Hier die Topologie. Ein Identity Provider stellt audience-gebundene Tokens aus, mit einem Realm pro Mandant. Clients übergeben diese Tokens an einen gemeinsamen Resource Server oder ein Gateway innerhalb der Enterprise Trust Boundary. Der Server validiert Audience, erzwingt Per-Tool-Scope, pinnt den Mandanten-Realm und erreicht erst dann Tools, Daten und Downstream-APIs, jeweils pro Mandant isoliert.

Der Fehler in den meisten Multi-Tenant-Texten ist, Isolation als Datenbankthema zu behandeln. Ist es nicht. Mandantenfähigkeit muss auf jeder Ebene erzwungen werden, und die Mandanten-Identität kommt aus einem verifizierten Token-Claim, nie aus einer Tool-Eingabe, die das Modell beeinflussen kann. Die Tabelle unten ist die Checkliste, die wir pro Ebene durchgehen.

"Die Mandanten-Identität ist ein verifizierter Token-Claim. In dem Moment, in dem sie aus einem Tool-Argument kommt, das das Modell schreiben kann, ist deine Isolation Theater."

Wie funktionieren Per-Tool-Scopes und Step-up-Autorisierung?

Das Core-Protokoll behandelt Scopes auf OAuth-Ebene, nicht pro einzelnem Tool, echte Per-Tool-Autorisierung baust du also obendrauf. Die Spec gibt dir die Primitive. Fang minimal an und vermeide Sammel-Scopes wie all oder full-access. Braucht ein Tool mehr, als das aktuelle Token gewährt, sollte der Server 403 mit WWW-Authenticate: Bearer error="insufficient_scope", allen für die aktuelle Operation nötigen Scopes und der resource_metadata-URI zurückgeben. Ein nutzerbezogener Client sollte die Vereinigung daraus und den zuvor angeforderten Scopes autorisieren und nur begrenzt oft wiederholen.

In der Praxis mappen wir Identity-Provider-Gruppen und SCIM-Rollen auf Scopes und gaten dann jedes Tool auf einen benötigten Scope. Eine Analyst-Rolle trägt invoices:read und sieht die Read-Tools; sie trägt nie ledger:write. Dieselbe Disziplin wenden wir in einem Authorization-Review an, und genau das testet ein Procurement-Team.

Wie fügst du einem MCP-Server Enterprise SSO hinzu?

Es gibt zwei Formen, und die Wahl treibt den Großteil deiner Betriebskosten.

Die erste ist OAuth pro Server: Jeder MCP-Server richtet seine authorization_servers-Metadata auf den Workforce Identity Provider. Sauber für ein, zwei Server, repetitiv im Flottenmaßstab. Die zweite ist ein MCP-Gateway: ein einziger, policy-durchgesetzter Eingang vor jedem Server, der Discovery, Token-Validierung, Scope-Mapping, Token Exchange und Audit zentralisiert. Für ein Unternehmen mit vielen Servern über viele Mandanten ist das Gateway meist die richtige Antwort, weil du eine Stelle zum Erzwingen der Isolation und eine Stelle zum Auditieren hast.

Zu den Protokollen: Die Revision 2026-07-28 verlangt vom Authorization Server RFC-8414-Metadata oder OpenID Connect Discovery; Clients müssen beide Discovery-Mechanismen unterstützen. Protected Resource Metadata darf mehrere Authorization Server auflisten. Der Client wählt einen aus und muss Credentials und Tokens nach Issuer getrennt halten. Einen nativen SAML-Flow gibt es in MCP nicht. Ein reines SAML-Unternehmen brückt über seinen Identity Provider oder einen Broker, der OAuth oder OIDC für den MCP-Server anbietet.

Wie governst du Client-Registrierung und Credential-Lebensdauern?

Die Revision 2026-07-28 stuft Dynamic Client Registration formell als veraltet ein. Clients, die alle Optionen unterstützen, sollten vorregistrierte Credentials bevorzugen, danach Client ID Metadata Documents, wenn der Authorization Server sie ausweist, DCR nur als rückwärtskompatiblen Fallback und zuletzt manuell eingegebene Client-Informationen. Gespeicherte vorregistrierte oder per DCR bezogene Credentials müssen an den ausstellenden Issuer gebunden bleiben und dürfen nicht bei einem anderen Authorization Server wiederverwendet werden. Authorization Server, die Client ID Metadata Documents abrufen, sollten SSRF abwehren, Redirect-URIs exakt prüfen und bei reinen Localhost-Redirects klar warnen. Unternehmen sollten Registrierung an einen Mandanten binden und unbekannte Clients durch eine Admin-Review-Queue schicken.

Die aktuelle MCP-Spec sagt, dass Authorization Server kurzlebige Access Tokens ausstellen sollten, Refresh Tokens für Public Clients rotieren müssen und Refresh Tokens auch ganz verweigern dürfen. Clients müssen Refresh Tokens bei Übertragung und Speicherung schützen, Access Tokens aus URL-Query-Strings heraushalten und das Bearer Token bei jedem HTTP-Request senden. Konkrete Defaults, die wir als Startpunkt nutzen:

Welche Audit-Events musst du erfassen?

Die Core-Spec hat keine eigene Audit-Logging-Anforderung, aber die Passthrough-Analyse macht den Fall für dich: Passthrough bricht den Audit-Trail, weil Downstream-Logs die falsche Identität zeigen. In einem Multi-Tenant-System ist Audit der Weg, um zu beweisen, dass die Isolation gehalten hat. Logge diese pro Mandant, mit einer Correlation ID, die den Downstream-Hop übersteht.

• Token-Validierungsergebnisse: akzeptiert, abgelehnt wegen Audience, abgelehnt wegen Issuer, abgelaufen.
• Autorisierungsentscheidungen: aufgerufenes Tool, benötigter Scope, gewährter Scope, Allow oder Deny.
• Step-up-Events: angefragter Scope und die gewährte Teilmenge.
• Token Exchange: welche Downstream-Audience geprägt wurde, für welches Subject und welchen Actor.
• Mandanten-Kontext: der verifizierte Mandanten-Claim in jedem Eintrag, damit eine Query einem Mandanten, einem Nutzer und einem Tool zuzuordnen ist.

Pro Server, Gateway oder Managed Identity: was wählst du?

Eine kurze Entscheidungsmatrix für die drei tragfähigen Topologien.

Der Weg von einem Single-Tenant-Server zu einem mandantenfähigen ist kein Rewrite, wenn du ihn sequenzierst: zuerst den Mandanten-Claim einführen und den Issuer pinnen, Secrets in einen Vault pro Mandant verschieben, Row-Level Security auf Basis des Claims ergänzen, dann Tool-Sichtbarkeit filtern und Audit pro Mandant einschalten. Jeder Schritt ist für sich lieferbar und testbar. Teste Isolation adversarial, spiel das Token von Mandant A gegen die Daten von Mandant B und bestätige, dass es auf Token-Ebene abgelehnt wird, nicht bloß auf Query-Ebene gefiltert.

Quellen und weiterführende Links

• Model Context Protocol, Authorization specification (2026-07-28 revision)
• Model Context Protocol, Authorization server discovery
• Model Context Protocol, Client registration
• Model Context Protocol, Authorization security considerations
• Model Context Protocol, 2026-07-28 specification release
• Model Context Protocol, Authorization specification (2025-06-18 revision)
• MCP pull request 284, separating the resource server and authorization server roles
• RFC 9728, OAuth 2.0 Protected Resource Metadata
• RFC 8707, Resource Indicators for OAuth 2.0
• RFC 8414, OAuth 2.0 Authorization Server Metadata
• RFC 9207, OAuth 2.0 Authorization Server Issuer Identification
• RFC 7591, OAuth 2.0 Dynamic Client Registration
• OAuth Client ID Metadata Document (IETF draft)
• OpenID Connect Discovery 1.0
• RFC 8693, OAuth 2.0 Token Exchange
• RFC 9068, JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
• RFC 6750, OAuth 2.0 Bearer Token Usage
• OAuth 2.1 Authorization Framework (IETF draft)