MCP Gateway OAuth: Ressourcenbindung, Discovery und Step-Up
Implementieren Sie das MCP-Gateway OAuth mit geschützten Ressourcenmetadaten, kanonischen Ressourcenindikatoren, Publikumsvalidierung, PKCE und Bounded Step-up Retries.
Ein MCP-Gateway sollte Token für die kanonische MCP-Serverressource anfordern und akzeptieren, nicht für ein generisches Ökosystempublikum. resource Parameter in Autorisierungs- und Token-Anfragen und Publikumsvalidierung auf dem geschützten Server.
Dies sind Transport-Zugangskontrollen innerhalb einer breiteren MCP-GatewayDie exakte Autorisierung von Werkzeugen erfordert weiterhin Richtlinien für den Werkzeugnamen, Argumente und den aktuellen Geschäftszustand.
Discovery defensiv umsetzen
Die MCP-Berechtigungsspezifikation erfordert, dass geschützte MCP-Server Metadaten veröffentlichen, die von RFC 9728Eine 401-Antwort kann den Client auf resource_metadataKunden unterstützen auch das bekannte URI-Formular.
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource", scope="files:read"
{
"resource": "https://mcp.example.com",
"authorization_servers": ["https://auth.example.com"],
"scopes_supported": ["files:read"]
}
Eine Berechtigungsserver-Vertrauensrichtlinie anwenden. Ein servergesteuertes Metadatendokument darf Unternehmensclients nicht zu einem Emittenten im Internet umleiten.
Halten Sie den Ressourcenwert stabil
RFC 8707 definiert Ressourcenindikatoren; MCP-Clients umfassen resource Verwenden Sie die spezifischste kanonische Server-URI, die die beabsichtigte geschützte Ressource und das Griffschema, die Host- und Trailing-Slash-Normalisierung konsistent identifiziert.
Testen Sie diese Fälle:
| Fall | Erwartetes Ergebnis |
|---|---|
| Token Audience ist ein weiterer MCP-Server | 401 |
| Ressourcenparameter weggelassen | Autorisierungsanfrage abgelehnt oder inkompatibler Fluss aufgetaucht |
| Query String enthält Zugriffstoken | Ablehnen und Verhindern von Protokollierung |
| Metadaten-Emittent ist für Mieter nicht vertrauenswürdig | Entdeckung abgelehnt |
| Großbuchstaben-Host normalisiert sich auf genehmigten Host | deterministisches Ergebnis |
| Fragment erscheint in Ressource URI | Ablehnung |
Der MCP-Server muss sein eigenes Token validieren. Eine Gateway-Validierung rechtfertigt nicht die Annahme von vertrauenswürdigen Identitäts-Headern über eine nicht authentifizierte Upstream-Verbindung.
Gebundenes Step-up-Verhalten
Wenn eine Anfrage keinen Umfang hat, kann der Server 403 mit insufficient_scopeEin client, der für einen benutzer handelt, kann die autorisierung mit den neuen bereichen wiederholen.
Scope Step-up gewährt Zugang. Es sollte nicht stillschweigend eine Geschäftsgenehmigung erfüllen. payments:submit Token beweist nicht, dass ein Finanzautor einen bestimmten Lieferanten, Betrag und Ziel akzeptiert hat.
Schutz von Zertifikaten
Verwenden Sie Authorization-Header, niemals URI-Abfrageparameter. Wenden Sie PKCE auf Authorization-Code-Clients an, wie es die MCP-Spezifikation und die aktuelle OAuth-Sicherheitspraxis erfordern. Halten Sie Aktualisierungs- und Upstream-Token in einem Credential-Broker anstelle von Modellspeicher, Tool-Argumenten oder Aktionsquittungen. RFC 9700 bietet aktuelle OAuth-Sicherheitsrichtlinien, während DPoP definiert einen vom Sender eingeschränkten Token-Mechanismus.
Die MCP-Sicherheitskontrollen Artikel verwandelt dies in Tests. OAuth Scopes versus Business Authority erklärt die nächste Autorisierungsschicht. MCP Autorisierungsartikel für den Produktstandpunkt.
Dieser Entwurf wird anhand der Spezifikation MCP 2025-11-25 überprüft und sollte vor der Veröffentlichung erneut mit den bereitgestellten Client- und Serverversionen verglichen werden.
OAuth Umsetzungsfragen
Was ist die kanonische MCP-Ressource?
Ein Pfad kann Server auf einem Host unterscheiden, Schema und Hostgehäuse, Porthandling und Trailing-Slash-Verhalten standardisieren, dann den Wert in geschützten Ressourcen-Metadaten veröffentlichen Client, Autorisierungsserver, Gateway und Ressourcenserver müssen zustimmen.
Kann ein Token mehrere MCP-Server abdecken?
Wenn ein Autorisierungsserver ein zusammengesetztes Ressourcenmodell unterstützt, überprüfen Sie, wie jeder Server die Zielgruppe validiert und wie Bereiche isoliert bleiben. Ein Gateway sollte ein Multi-Ressourcen-Token nicht in implizite Berechtigung für jeden zugelassenen Server verwandeln.
Wie sollen Metadaten zwischengespeichert werden?
Validierte Cache-Steuerelemente innerhalb eines maximal zulässigen Alters ehren und den Cache durch kanonische Ressourcen- und Mandanten-Vertrauensrichtlinien schlüsseln. den abgerufenen Emittentensatz aufzeichnen und Metadaten verdauen. Während des Ausfalls eine explizite Risikoklassenregel befolgen. Nicht auf unbestimmte Zeit geänderte Autorisierungsserver-Metadaten verwenden, da die Entdeckung außerhalb des Hauptanforderungspfads erfolgt.
Welche Umleitungs-URIs sind für lokale Kunden sicher?
Befolgen Sie die MCP- und OAuth-Regeln für eine genaue Redirect-Validierung und Localhost-Handhabung. Bevorzugen Sie Loopback-Adressen und ephemere Ports, wenn das Clientprofil sie unterstützt. Akzeptieren Sie keine Platzhalter-Hosts oder offene Redirects. Testen Sie bösartige Geschwisterdomänen, verschlüsselte Pfadänderungen und einen von einer anderen Browsersitzung initiierten Rückruf.
Wann sollte Scope Step-up aufhören?
Retriees pro Ressource und Operation begrenzen, die angeforderte Scope-Historie beibehalten und auf Wiederholungen stoppen insufficient_scope. Ein Server kann falsch konfiguriert oder feindselig sein. Der Client sollte den Benutzer nicht ständig auffordern oder Bereiche akkumulieren. Die Geschäftsgenehmigung bleibt getrennt, so dass ein erfolgreiches Step-up keine Zahlungs- oder Produktionsaktion autorisiert.
Was sollte bei einem OAuth-Versagen aufgezeichnet werden?
Ressourcen, Aussteller, Client-Kennung, angeforderter Scope-Satz, Fehlerklasse und Korrelations-ID ohne Token-Werte oder Autorisierungscodes, getrennte Erkennungs-, Autorisierungsserver- und Ressourcenserver-Ausfälle, die es den Betreibern ermöglichen, einen unbekannten Aussteller von einer falschen Zielgruppe oder einem unzureichenden Scope zu unterscheiden, ohne Anmeldeinformationen in durchsuchbaren Protokollen freizulegen.
Ein korrektes Metadatendokument an der Host-Root hilft nicht, wenn der bereitgestellte MCP-Endpunkt eine pfadspezifische Ressource benötigt, ein Reverse-Proxy die kanonische URI umschreibt oder eine Region veraltete Emittentenmetadaten bedient. WWW-Authenticate Bestätigen Sie, dass der gleiche Ressourcenwert den gesamten Fluss überdauert und als Zielgruppe erscheint, die der geschützte Server validiert.
Wiederholen Sie nach einer Gateway- oder DNS-Migration. Canonical-Ressourcenänderungen können Clients stranden lassen oder Betreiber dazu verleiten, alte und neue Zielgruppen auf unbestimmte Zeit zu akzeptieren. Legen Sie einen begrenzten Übergang fest und testen Sie, ob die alte Zielgruppe nicht mehr funktioniert, wenn sie endet.