OAuth auf der MCP-Ebene: Wie wir enterprise-fähiges Token-Management für KI-Agenten gelöst haben

Ein Einblick in die Auth-Architektur des TrueFoundry MCP Gateways — drei Ebenen, zwei OAuth-Flows, ein Credential Vault — erzählt aus der Perspektive eines Kunden, der es in der Produktion einsetzt.

Ein Montagmorgen bei Northwind. Um 8:47 Uhr an einem Montagmorgen erhält der On-Call-Ingenieur bei Northwind Logistics — einer fiktiven, aber realistischen Logistikplattform mit 50 Entwicklern — eine Slack-Benachrichtigung. Ihr interner KI-Assistent, Cargo Copilot, gibt für jeden Tool-Aufruf an Jira und GitHub den Statuscode 401 zurück. Die Ursache ist das Laptop eines Entwicklers, das am Wochenende am Flughafen verloren ging. Die IT-Abteilung hat die SSO-Sitzung des Laptops widerrufen. Das Laptop enthielt jedoch auch OAuth-Token für GitHub, Slack, Jira und einen internen Analysedienst — jeweils in die Editor-Einstellungen und Dotfiles des Entwicklers kopiert. Die Sicherheitsabteilung kann nicht mit Sicherheit sagen, welche Scopes offengelegt wurden, auf welchen anderen Rechnern diese Token gespiegelt wurden (da Entwickler sich gegenseitig helfen) oder wie alle Token widerrufen werden können, ohne den Morgen aller Mitarbeiter zu beeinträchtigen.

Der Vorfall bei Northwind ist kein Einzelfall. So sieht die Zugangsdatenverwaltung bei den meisten Unternehmen sechs Monate nach der begeisterten MCP-Einführung aus. Der Rest dieses Beitrags erzählt die architektonische Geschichte, wie Northwind — und andere TrueFoundry-Kunden — verhindern, dass sich ein solcher Vorfall wiederholt.

1. Das Problem des Zugangsdaten-Wildwuchses: Wie 50 Entwickler × 8 MCP Server in der Praxis aussehen

Northwind beschäftigt etwa fünfzig Entwickler, die MCP-fähige IDEs aktiv mit acht Servern nutzen — GitHub, Slack, Google Workspace, Jira, ein interner Analysedienst, eine interne Logistik-API, Zendesk und ein proprietärer Routenplanungsdienst. Nach der einfachen Arithmetik ergibt das vierhundert aktive Verbindungen. In der Praxis sind es deutlich mehr Zugangsdaten-Platzierungen, wenn man Schlüsselbund-Einträge, Editor-Einstellungen, Shell-Umgebungsdateien, CI-Variablen und die Kopien mitzählt, die beim Onboarding eines Teamkollegen angefertigt werden.

Der Explosionsradius einer kompromittierten Workstation beschränkt sich nicht auf ein einzelnes Token. Er entspricht einem Token multipliziert mit den an diesen Provider gebundenen Scopes, der Lebensdauer des Tokens (oft 90 Tage oder länger bei Personal Access Tokens), der Anzahl der Rechner, die es gespiegelt haben, und dem Fehlen eines zentralen Widerrufs. Wenn ein Slack-OAuth-Token das Lesen des Kanalverlaufs ermöglicht und ein lokal gespeichertes GitHub-Token das Lesen von Repositorys erlaubt, wird eine einzelne Datenexfiltration zu einem systemübergreifenden Vorfall, noch bevor das Sicherheitsteam reagieren kann. Lokale MCP-Zugangsdaten sind zudem betrieblich unsichtbar: Es gibt keinen einheitlichen Audit-Trail, keine erzwungene Rotation, keine Richtlinienprüfung vor der Ausführung eines Tools und keine schnelle Möglichkeit zu beantworten, wer was aufrufen darf.

Das Gateway-Muster schließt diese Lücke. Entwickler authentifizieren sich einmalig beim Gateway, und das Gateway übernimmt die nachgelagerte Authentifizierung gemäß dem konfigurierten Modell jedes Servers — genau das Design, das in der TrueFoundry MCP Gateway-Übersicht und den Authentifizierungs- und Sicherheitsdokumenten beschrieben ist. Der Vorteil liegt nicht nur in der Konsolidierung. Er besteht darin, dass die Authentifizierung zu einer Eigenschaft der Infrastruktur wird und nicht mehr von jedem einzelnen Laptop im Unternehmen abhängt.

2. Die Drei-Ebenen-Auth-Architektur: Inbound, Access Control und Outbound

Die erste Architekturentscheidung besteht darin, drei Ebenen zu trennen, die in lokalen Entwickler-Setups routinemäßig vermischt werden. Die TrueFoundry-Dokumentation zu Authentifizierung und Sicherheit beschreibt dies als ein dreiteiliges System: Inbound-Authentifizierung, Zugriffskontrolle (Access Control) und Outbound-Authentifizierung. Die Dokumentation stellt explizit heraus, dass die Inbound- und Outbound-Schichten unabhängig sind, was den eigentlichen architektonischen Gewinn darstellt.

• Inbound-Authentifizierung. Wer ruft das Gateway auf? TrueFoundry unterstützt vier Methoden: TrueFoundry API Key (PAT), Virtual Account Token, Identity Provider Token (ein Okta/Auth0/Azure AD JWT, das über einen konfigurierten Identity Provider validiert wird) und TrueFoundry OAuth (verwendet von IDEs wie Cursor und VS Code).
• Zugriffskontrolle (Access Control). Was darf die aufgelöste Identität tun? Jeder MCP Server hat Collaborators — Benutzer, Teams oder Virtual Accounts — mit rollenbasierten Berechtigungen. Eine Berechtigungseinschränkung auf Tool-Ebene wird erreicht, indem Tools von mehreren MCP Servern in einem Virtual MCP Server kombiniert werden, der nur eine kuratierte Teilmenge bereitstellt.
• Outbound-Authentifizierung. Wie erreicht das Gateway den jeweiligen nachgelagerten Server? Es werden sieben Methoden unterstützt: OAuth2 (Authorization Code), OAuth2 (Client Credentials), API Key (Shared), API Key (Individual), No Auth, Token Passthrough und Token Forwarding via x-tfy-mcp-headers.

‍

Das Designprinzip ist einfach: Das Zugangsdaten-Token, das zum Erreichen des Gateways verwendet wird, ist niemals das Token, das das nachgelagerte Tool erreicht. Eine Inbound-Rotation berührt keinen Provider-OAuth-Status. Ein GitHub MCP Server kann benutzerbezogenes OAuth verwenden, während der interne Analysedienst Client Credentials nutzt — im selben Agenten, im selben Anforderungsablauf. Das Gateway ist sowohl der Punkt für die Richtliniendurchsetzung (Policy Enforcement Point) als auch der Credential-Broker.

3. 2LO vs. 3LO: Auswahl des richtigen OAuth-Grant-Typs für jeden MCP Server

In der Enterprise-Sprache beziehen sich 2LO und 3LO auf zwei Grant-Typen aus RFC 6749 (OAuth 2.0), gemappt auf die Art und Weise, wie Endbenutzer einbezogen werden.

Two-legged OAuth (2LO) verwendet den Client Credentials Grant. Das Gateway hält eine client_id und ein client_secret, sendet grant_type=client_credentials an den Token-Endpunkt des Providers, empfängt ein kurzlebiges access_token und verwendet dieses Token bei jeder Anforderung an den MCP Server. Kein Browser, keine Benutzerzustimmung. Es ist die richtige Wahl für Server-zu-Server-Integrationen: interne Analyse-APIs, Backend-Microservices, interne Datendienste.

Three-legged OAuth (3LO) verwendet den Authorization Code Grant. Jeder Endbenutzer wird zum Provider (GitHub, Slack, Google) weitergeleitet, um den Zugriff auf seine spezifischen Ressourcen zu autorisieren. Das Gateway speichert ein benutzerbezogenes refresh_token, verwaltet eine verschlüsselte Zuordnung von user_id → {access_token, expires_at, refresh_token, scopes, provider_metadata} und rotiert das Access Token automatisch.

Wie Northwind entschieden hat

Die acht MCP Server von Northwind teilen sich ungefähr in zwei Hälften. GitHub, Slack, Jira, Google Workspace und Zendesk sind allesamt benutzerbezogene Tools — der Wert von „führe dies als Alice aus“ überwiegt den betrieblichen Aufwand eines benutzerbezogenen Tokens. Diese nutzen 3LO. Der interne Analysedienst, die Logistik-API und der Routenplanungsdienst stellen unternehmensweite Daten bereit; hier macht ein benutzerbezogenes OAuth keinen Sinn, und ein einzelner gemeinsamer Client Credentials Grant ist sowohl einfacher als auch leichter zu auditieren. Diese nutzen 2LO.

Wie das Konfigurationsmodell aussieht

Hinweis zu dieser Konfigurationsansicht

TrueFoundry registriert MCP Server über die Benutzeroberfläche (Settings → MCP Servers → Add MCP Server) und nicht über eine vom Kunden verwaltete YAML-Datei, obwohl die Konfiguration auch deklarativ über tfy apply angewendet werden kann. Das folgende YAML zeigt das Konfigurationsmodell pro Server — dieselben Felder, die Sie in der Benutzeroberfläche ausfüllen — unter Verwendung des verifizierten Schemas von TrueFoundry (provider-account/mcp-server-group mit verschachteltem integrations).

Der Befehl zum Anwenden des obigen YAML lautet:

Drei Dinge sind zu beachten. Erstens ist tfy-secret:// das kanonische FQN-Referenzschema, das TrueFoundry für Secrets verwendet, die in einer TrueFoundry-Secret-Gruppe gespeichert sind, mit dem durch Doppelpunkt getrennten Format tfy-secret://<tenant>:<secret-group>:<secret-key>, das in der Dokumentation zu Umgebungsvariablen und Secrets dokumentiert ist. Der Wert befindet sich in Ihrem Secret Manager (AWS SSM, GCP Secret Manager, HashiCorp Vault, Azure Key Vault); TrueFoundry löst das FQN zur Laufzeit auf, sodass die obige Datei sicher in einem Git-Repository gespeichert werden kann. Zweitens ist authorized_subjects die RBAC-Liste pro Server — eine Mischung aus Teams und Virtual Accounts —, die es ermöglicht, dass derselbe MCP Server menschliche Entwickler (deren PATs zu einer Teammitgliedschaft aufgelöst werden) und geplante Service-Account-Jobs (deren Virtual Account Tokens auf virtualaccount:-Subjekte mappen) ohne Konfigurationsabweichungen bedient. Drittens setzt der 3LO-Eintrag code_challenge_methods_supported: [S256] — PKCE wird heute für jeden Authorization Code Client empfohlen und ist in der neueren MCP-Spezifikation vom 25.11.2025 obligatorisch.

Auf der Client-Seite liest der Agent niemals Authentifizierungsmodi aus. Er wählt eine einzige Gateway-URL, übergibt ein Inbound-Zugangsdaten-Token und das Gateway fügt das richtige Outbound-Zugangsdaten-Token pro Server ein:

4. Token-Lebenszyklus-Management: Proaktives Refresh und konkurrierender Zugriff

Korrektheit bei OAuth bedeutet nicht nur, Token zu erhalten. Es geht darum, sie unter paralleler Last sicher zu betreiben. Das naive Design führt ein Refresh durch, wenn der Provider 401 zurückgibt oder wenn now ≥ expires_at gilt. Dieses Design funktioniert in Demos, scheitert jedoch am ersten Montag, an dem es auf die Realität trifft.

Spielen wir den Vorfall bei Northwind mit naivem Refresh durch: Am Montag um 8:47 Uhr gehen fünfzig Entwickler online, jeder Worker entdeckt unabhängig voneinander dasselbe abgelaufene GitHub-Token, fünfzig parallele Aufrufe von POST /token treffen vom selben Gateway bei GitHub ein und GitHub erzwingt ein Rate Limiting für alle Aufrufe. Cargo Copilot gibt für alle Benutzer den Statuscode 401 zurück, bis die Warteschlange abgearbeitet ist.

Das Muster, das in der Produktion standhält, besteht aus zwei Komponenten: proaktives Erneuern bei 80 % der TTL und Serialisierung der Erneuerung pro (Benutzer, Server) mit einem verteilten Lock.

Das Erneuern bei 80 % der TTL lässt Spielraum für Uhrzeitabweichungen (Clock Skew), Wiederholungsversuche, langsame Provider-Token-Endpunkte und bereits in Ausführung befindliche Anfragen. Das Lock pro (Benutzer, Server) verhindert ein Thundering-Herd-Problem gegenüber dem Provider. Das Double-Checked Read innerhalb des Locks ist nicht kosmetischer Natur: Es ermöglicht der ersten Anfrage, das Refresh durchzuführen, während die übrigen Anfragen das neu geschriebene Token wiederverwenden.

Zwei Feinheiten sind bei der Skalierung von Bedeutung. Erstens lautet der Cache-Schlüssel für Client-Credentials-Integrationen (server_id, provider_account); für Authorization-Code-Integrationen muss der Schlüssel user_id enthalten. Zweitens erfordern Provider, die Refresh-Token bei jeder Erneuerung rotieren — Google und Microsoft tun dies je nach Konfiguration —, dass der Schreibvorgang atomar erfolgt. Wenn das neue access_token vor dem neuen refresh_token geschrieben wird, führt ein Absturz dazu, dass der Benutzer mit einem ungültigen alten Refresh-Token blockiert wird und eine erneute Authentifizierung erzwungen werden muss.

5. Der Double-Auth-Flow: Ein vollständiges Sequenzdiagramm

Wenn die Ebenen getrennt sind und der Erneuerungspfad definiert ist, hat eine durchgehende MCP-Anfrage durch das Gateway eine präzise Struktur. Verfolgen wir einen Aufruf von Cargo Copilot — „Fasse die offenen Issues mit kritischer Schwere im Repository northwind/logistics-core zusammen“ — vom Agenten zu GitHub und zurück:

‍

Drei Eigenschaften dieses Ablaufs sind hervorzuheben. Der Agent erhält niemals das Access Token für GitHub; nur das Gateway besitzt es. Der MCP Server sieht die Inbound-TrueFoundry-Zugangsdaten von Northwind niemals, es sei denn, Token Passthrough ist explizit konfiguriert (mehr dazu in §7). Und das Sicherheitsteam von Northwind erhält einen einzigen verwalteten Anforderungspfad, bei dem Identität, Autorisierung und Audit an einem Ort erfasst werden — genau die Eigenschaft, die es ihnen ermöglicht hätte, die Frage vom Montagmorgen („Welche Scopes befanden sich auf diesem Laptop?“) in unter einer Minute zu beantworten.

Die MCP-Autorisierungsspezifikation verstärkt einen Teil dieses Bildes: Bearer-Access-Token müssen im Authorization-Request-Header und niemals in einem URI-Query-String gesendet werden. Diese Norm ist genau deshalb wichtig, weil sie Token aus Zugriffs-Logs, dem Browserverlauf und Proxy-Traces fernhält.

6. Credential-Vault-Integration: Warum Roh-Secrets niemals den Anwendungsspeicher berühren

Ein produktives Gateway sollte OAuth-Refresh-Token nicht wie gewöhnliche Anwendungsdaten behandeln. Client Secrets und Refresh Token sind langlebige Schlüssel zu den Systemen — das Durchsickern eines Slack-Refresh-Tokens kommt in den meisten Fällen dem Durchsickern des gesamten Slack-Workspace gleich.

Das Standardmuster ist Envelope Encryption. Das Gateway generiert für jeden Token-Datensatz einen zufälligen Datenverschlüsselungsschlüssel (Data Encryption Key, DEK), verschlüsselt das OAuth-Secret mit diesem DEK, verschlüsselt den DEK mit einem Master Key in einem KMS oder Secret Manager und speichert den verschlüsselten DEK zusammen mit dem Chiffretext. Beim Lesen fordert das Gateway den Vault auf, nur den DEK zu entschlüsseln, und entschlüsselt das Token dann in einem eng abgegrenzten Codepfad, der das Protokollieren oder Serialisieren von Klartext vermeidet.

In strengeren Bereitstellungen kann der Token-Austausch selbst in einen Sidecar oder eine Vault-Transit-Operation ausgelagert werden, sodass der Anwendungscode überhaupt kein rohes client_secret-Material erhält. Selbst mit einfacher Envelope Encryption ändert sich der Explosionsradius erheblich: Ein Datenbank-Dump allein reicht nicht aus (die DEKs werden nicht unverschlüsselt gespeichert), und ein Speicherabzug eines allgemeinen Anforderungs-Workers enthält mit viel geringerer Wahrscheinlichkeit umfangreiches Zugangsdaten-Material (nur die kürzlich angeforderten Schlüssel werden entschlüsselt und das auch nur für die Dauer der Anfrage).

Die Bereitstellung von Northwind verwendet AWS KMS als Master-Schlüsselspeicher und den TrueFoundry-Secret-Store für das verschlüsselte Material. Das Gateway liest niemals ein Provider-client_secret direkt; es liest ein TrueFoundry-Secret-FQN, ruft den Chiffretext ab und fordert KMS auf, diesen zu entschlüsseln. Die verbleibende bereitstellungsspezifische Arbeit — KMS-Schlüsselrotationsrichtlinie, Aufbewahrung von Audit-Protokollen, betriebliche Runbooks — liegt in der Verantwortung jedes Unternehmens, das das Gateway betreibt, und verdient eine dedizierte Überprüfung.

7. Token Passthrough vs. Token Forwarding: Sonderfälle und wann welche Variante zu nutzen ist

Zwei Muster klingen ähnlich, haben aber sehr unterschiedliche Sicherheitsauswirkungen. Sie sollten sorgfältig unterschieden werden, da eine fehlerhafte Verwendung beider Varianten den Großteil des Werts des Gateways zunichtemachen kann.

Token Passthrough ist für interne MCP Server geeignet, die dasselbe Enterprise-Identitätstoken validieren, das das Gateway bereits eingehend validiert hat. Die Logistik-API von Northwind ist ein Beispiel dafür: Das Gateway und die API vertrauen beide dem Okta-Tenant des Unternehmens, sodass die Weiterleitung des Okta-JWTs die Identität des Anrufers durchgehend aufrechterhält. Das Risiko besteht in der Verwechslung der Token-Audience: Ein für das Gateway ausgestelltes Token sollte nicht automatisch für jeden MCP Server gültig sein. RFC 8707 (Resource Indicators) existiert genau zu dem Zweck, Token an eine vorgesehene Ressource zu binden, und die MCP-Autorisierungsspezifikation verlangt nun, dass Clients einen resource-Parameter angeben und Server validieren, dass vorgelegte Token für sie ausgestellt wurden.

Token Forwarding funktioniert anders. Der x-tfy-mcp-headers-Header von TrueFoundry überträgt ein als String formatiertes JSON, das nach der Remote-MCP-Server-ID im <group>/<server>-Format indiziert ist. Hier ist das Format wörtlich aus der Dokumentation zu Virtual MCP Servern:

Betrachten Sie Token Forwarding als Notfalllösung und nicht als Standard. Der Wert des Gateways liegt genau in dem Token-Management, das hierbei übersprungen wird.

8. Latenz-Benchmarks: Was Token-Management bei jedem Tool-Aufruf hinzufügt

Ein Gateway führt Arbeitsschritte vor dem nachgelagerten MCP-Aufruf aus: Inbound-Auth-Validierung, Richtlinien-Lookup, Token-Lookup und gelegentlich ein Refresh. In einer gesunden Bereitstellung ist der Regelfall ein Cache-Hit — Token-Metadaten sind gültig, die verschlüsselte Token-Referenz ist im Arbeitsspeicher vorhanden.

Szenario-Rahmenwerte

Durch Kombination der obigen Komponentenkosten fügt das Gateway ungefähr Folgendes hinzu:

Zwei wesentliche Erkenntnisse lassen sich festhalten. Erstens: Der Regelfall ist ein Cache-Hit, und bei Werten im einstelligen Millisekundenbereich ist dieser im Vergleich zum umgebenden LLM-Aufruf (typischerweise Hunderte von Millisekunden bis Sekunden) und dem nachgelagerten MCP Server (typischerweise Zehner bis Hunderte von Millisekunden) unsichtbar. Zweitens: Der Pfad mit Cache-Miss und Erneuerung tritt zwar selten auf, ist aber teuer genug, um unter Last ins Gewicht zu fallen — weshalb §4 das proaktive Erneuern bei 80 % der TTL mit einem Lock pro (Benutzer, Server) vorschreibt. Mit proaktivem Erneuern sehen echte Benutzer die Erneuerungslatenz im Request-Pfad fast nie; das Gateway hat bereits im Voraus ein neues Token abgerufen.

Jedes Team sollte dennoch Server-Timing-Header, Token-Endpunkt-Dauer, Lock-Wartezeit, Vault-Entschlüsselungszeit und die nachgelagerte MCP-Latenz separat instrumentieren. Das Ziel besteht darin, zu beweisen, dass das Token-Management nicht die dominierende Komponente beim durchgehenden Tool-Aufruf des Agenten ist — die obigen Werte legen nahe, dass dies fast nie der Fall ist, aber Sie sollten dies mit Ihrem eigenen Provider-Mix überprüfen.

Die betriebliche Lösung für den Cache-Miss-Fall ist das Hintergrund-Refresh. Wenn das Gateway erkennt, dass ein Token den Schwellenwert von 80 % überschreitet, erneuert es einmalig im Request-Pfad und plant nachfolgende Erneuerungen ein, bevor Benutzer etwas davon merken. Bei hochvolumigen gemeinsamen Client-Credentials-Integrationen eliminiert dies nutzerseitige Erneuerungslatenzen nahezu vollständig. Bei benutzerbezogenen Authorization-Code-Integrationen kann das System aktiven Benutzern und häufig genutzten MCP Servern Priorität einräumen.

Vorher vs. Nachher: Sicherheits-Posture bei Northwind

9. FAQs

Ist OAuth auf der MCP-Ebene zwingend erforderlich?

Nein. Die MCP-Autorisierungsspezifikation macht Autorisierung optional, aber HTTP-basierte Implementierungen, die sie unterstützen, sollten der Spezifikation entsprechen. In der Praxis sollten Unternehmen mit umfangreichen Tool-Landschaften die Authentifizierung zentralisieren, lange bevor sie sie als streng obligatorisch betrachten.

Sollte jeder MCP-Server 3LO verwenden?

Nein. Verwenden Sie Authorization Code (3LO), wenn der Agent im Namen der Ressourcen eines menschlichen Benutzers agiert — Slack, GitHub, Gmail, CRM-Tools. Verwenden Sie Client Credentials (2LO), wenn der nachgelagerte Server die Anwendung oder das Gateway selbst authentifiziert. Das Mischen beider Verfahren innerhalb eines Virtual MCP Server ist normal und zu erwarten.

Eliminiert ein Gateway providerseitige Berechtigungen?

Nein. Es ergänzt sie. Slack, GitHub, Google und interne APIs setzen weiterhin ihre eigenen Scopes und Ressourcenberechtigungen durch. Das Gateway fügt darüber eine göbere, schnellere Richtlinienschicht hinzu — auf Server-Ebene, Tool-Ebene, Team-Ebene — sowie einen einheitlichen Audit-Trail über alle hinweg.

OAuth 2.0 oder OAuth 2.1?

Das TrueFoundry-Gateway beherrscht die OAuth 2.0-Grants, die reale Provider heute unterstützen: Authorization Code (mit PKCE), Client Credentials und Refresh-Token. Die MCP-Autorisierungsspezifikation selbst zielt auf OAuth 2.1 ab, was im Wesentlichen OAuth 2.0 plus den Sicherheits-Best-Practices entspricht, die in modernen Bereitstellungen bereits als obligatorisch gelten (PKCE überall, kein Implicit Grant, kein Password Grant). Für praktische Zwecke konvergieren die beiden; wir folgen den OAuth 2.1-Empfehlungen, wo sie das Verhalten verschärfen.

Wie sieht es mit der neueren MCP-Spezifikation vom 25.11.2025 aus?

Die Überarbeitung vom November 2025 ergänzt verpflichtendes PKCE für alle Clients, formalisiert Client ID Metadata Documents (CIMD) als bevorzugte Client-Registrierungsmethode und führt Step-up-Autorisierung für inkrementelle Scope-Zustimmungen ein. Diese Maßnahmen verschärfen die Sicherheit, ohne die Architektur in diesem Beitrag außer Kraft zu setzen. Wir verfolgen diese Entwicklungen und binden die Unterstützung ein, sobald sie im Ökosystem ausreift.

Wo ordnet sich TrueFoundry ein?

Das TrueFoundry MCP Gateway ist eine Produktionsimplementierung dieser Architektur: eine zentrale Server-Registry, konfigurierbare eingehende Authentifizierung, Zugriffskontrolle, mehrere ausgehende Authentifizierungsmodi und Lebenszyklusverwaltung für Token. Dieser Beitrag beschreibt das Design; die Dokumentation zu Authentifizierung und Sicherheit dient als betriebliche Referenz. Für die hier behandelten Implementierungsmuster siehe auch die Dokumente zu Auth Overrides und Virtual MCP Server.

Machen Sie den nächsten Schritt

Wenn Sie eine Führungskraft in den Bereichen Plattform, Sicherheit oder AI-Infrastruktur sind und MCP in größerem Maßstab betreiben, ist die Maßnahme mit der größten Wirkung, jeden aktiv genutzten MCP-Server zu inventarisieren, jeden dem richtigen Modell für eingehende Authentifizierung, Richtlinien und ausgehende Authentifizierung zuordnen und zu entscheiden, wo die Zentralisierung tatsächlich Vorteile bringt. Das Mapping von Northwind dauerte zwei Nachmittage; die Migration selbst nahm einen einzigen Sprint in Anspruch. Wir gehen diese Übung gerne gemeinsam mit Ihrem Team durch.

Architektur lesen: TrueFoundry MCP Gateway Authentifizierung und Sicherheit. Oder buchen Sie eine Überprüfung der Unternehmenssicherheitsarchitektur mit unserem Team.

Weiterführende Literatur

Alle Zitate in diesem Beitrag sind im Text verlinkt. Die folgenden Referenzen fassen dieselben URLs für die Druckbarkeit und zur Absicherung gegen veraltete Links zusammen.

• Übersicht zum TrueFoundry MCP Gateway. https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-overview
• TrueFoundry MCP Gateway Authentifizierung und Sicherheit. https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-gateway-auth-security
• TrueFoundry Auth Overrides. https://www.truefoundry.com/docs/ai-gateway/mcp/mcp-server-auth-overrides
• TrueFoundry Virtual MCP Server. https://www.truefoundry.com/docs/ai-gateway/mcp/virtual-mcp-server
• Verwendung des TrueFoundry MCP Gateway in Ihrem Agenten. https://www.truefoundry.com/docs/ai-gateway/mcp/use-mcp-gateway-in-agent
• TrueFoundry Identity Providers. https://www.truefoundry.com/docs/platform/identity-providers
• TrueFoundry Secret Manager im AI Gateway. https://www.truefoundry.com/docs/ai-gateway/secret-manager-in-ai-gateway
• TrueFoundry Umgebungsvariablen und Secrets (tfy-secret:// FQN-Format). https://www.truefoundry.com/docs/environment-variables-and-secrets
• Verwendung von tfy apply mit TrueFoundry (provider-account / integrations YAML-Muster). https://docs.truefoundry.com/docs/using-tfy-apply
• Okta-Nebenläufigkeitsgrenzen (Hinweise zu API-Antwortzeiten). https://developer.okta.com/docs/reference/rl2-concurrency/
• WorkOS: RS256 vs. HS256 (JWT-Verifizierungs-Benchmarks). https://workos.com/blog/rs256-vs-hs256-jwt-signing-algorithms
• AWS KMS-Dokumentation (Hinweise zur Entschlüsselungslatenz). https://aws.amazon.com/kms/faqs/
• Model Context Protocol Autorisierungsspezifikation, 18.06.2025. https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
• RFC 6749: Das OAuth 2.0 Autorisierungs-Framework. https://datatracker.ietf.org/doc/html/rfc6749
• RFC 8707: Resource Indikatoren für OAuth 2.0. https://datatracker.ietf.org/doc/rfc8707/
• RFC 9728: OAuth 2.0 Geschützte Ressourcen-Metadaten. https://datatracker.ietf.org/doc/html/rfc9728/

Hinweis: Northwind Logistics ist ein fiktives Unternehmen, das verwendet wird, um das Design in einer konkreten Bereitstellung zu veranschaulichen. Das in §3 gezeigte Konfigurationsmodell dient der Veranschaulichung; Produktions-MCP-Server werden über die TrueFoundry-Benutzeroberfläche registriert oder über tfy apply angewendet.

‍