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, auf die Spec-Revision 2025-11-25 bezogen und zeichnet das eine Diagramm, das sonst niemand zeichnet: die komplette Trust Boundary vom Identity Provider bis zur mandantengetrennten Datenebene. Geschrieben aus Wavects Arbeit an KI-Produkten und Security-Hardening.

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, und genau diese Trennung macht Enterprise Single Sign-on überhaupt erst möglich. 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 nur für HTTP-Transporte definiert. Ein Server hinter einem STDIO-Transport sollte dieser Spec gar 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 2025-11-25.

Beachte die zwei Versions-Deltas, die Leute stolpern lassen. Die Revision 2025-11-25 hat Dynamic Client Registration von SHOULD auf MAY herabgestuft und eine verpflichtende PKCE-S256-Methode ergänzt, plus die Anforderung, dass der Client PKCE-Support vorher prüft. Wenn die Auth-Server-Metadata kein code_challenge_methods_supported ausweist, muss ein konformer Client den Flow verweigern.

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. Bei der Challenge muss der Server 401 Unauthorized mit einem WWW-Authenticate-Header zurückgeben, der die resource_metadata-URL trägt, gemäß RFC 9728. Die Revision 2025-11-25 lässt den Client auch direkt die Well-known-URI probieren. Bei Authorization- und Token-Request muss der Client einen resource-Parameter mit der kanonischen URI des MCP-Servers senden, und zwar unabhängig davon, ob der Auth Server das unterstützt.

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()   # never from a session
  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

Was hier fehlt, ist entscheidend: kein Session-Lookup zur Authentifizierung. Die Spec ist explizit, dass Server jeden eingehenden Request verifizieren müssen und Sessions nicht zur Authentifizierung nutzen dürfen. Session-Identifier, falls du sie überhaupt nutzt, müssen nicht-deterministisch und an die Nutzeridentität gebunden sein, damit ein geratener Identifier keinen anderen Mandanten impersonieren kann.

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 der Upstream-Authorization-Server prägt. Die Spec sagt dir, was du nicht tun sollst (das eingehende Token nicht durchreichen), überlässt das Wie aber dem Ökosystem. Das dominante Muster 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, definiert die Revision 2025-11-25 einen sauberen Step-up: Der Server gibt 403 mit WWW-Authenticate: Bearer error="insufficient_scope" und dem benötigten Scope zurück, der Client führt eine inkrementelle Autorisierung nur für diesen Scope aus und wiederholt.

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: OIDC ist in der Revision 2025-11-25 erstklassig, sie verlangt vom Auth Server RFC-8414-Metadata oder OpenID Connect Discovery und vom Client, beide zu versuchen. Natives SAML gibt es in MCP nicht. Ein reines SAML-Unternehmen brückt über seinen Identity Provider oder einen Broker, der eine OAuth- oder OIDC-Front für den MCP-Server anbietet.

Wie governst du Client-Registrierung und Credential-Lebensdauern?

Dynamic Client Registration war der Schwachpunkt früher Deployments, weil es beliebige Clients enrollen ließ. Die Revision 2025-11-25 stuft es auf MAY herab und bevorzugt ein dreistufiges Modell: vorregistrierte Credentials für bekannte Clients, dann Client ID Metadata Documents, bei denen der Client eine HTTPS-URL als client_id nutzt, dann DCR als Fallback. Erlaubst du eines der letzten beiden, allowliste Issuer und achte auf die SSRF- und Localhost-Redirect-Risiken, die die Spec nennt. Unternehmen sollten die Registrierung an einen Mandanten binden und unbekannte Clients durch eine Admin-Review-Queue schicken.

Credential-Lebensdauern folgen OAuth 2.1: kurzlebige Access Tokens ausstellen, Refresh Tokens für Public Clients rotieren, Tokens sicher speichern, Tokens aus URL-Query-Strings heraushalten und das Bearer-Token bei jedem Request senden. Konkrete Defaults, mit denen wir starten:

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 (2025-11-25 revision)
• Model Context Protocol, Authorization specification (2025-06-18 revision)
• Model Context Protocol, Security Best Practices (token passthrough, confused deputy)
• 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 7591, OAuth 2.0 Dynamic Client Registration
• 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)