Authentifizierung mit dem MCP-OAuth-Flow

MCP-Clients, welche die MCP-Autorisierungsspezifikation implementieren, können sich automatisch über OAuth 2.0 bei UiPath authentifizieren. Der Client führt die Autorisierungsservererkennung durch, stellt seine OAuth-Identität bereit, ruft Token ab und aktualisiert sie bei Bedarf. Benutzer und Administratoren müssen keine OAuth-Anwendungen erstellen oder Zugriffstoken manuell verwalten.

Auf der Benutzerseite ist der einzige manuelle Schritt die Anmeldung bei UiPath Cloud im Browser. Clientbereitstellung, Tokenausgabe und Tokenaktualisierung werden zwischen dem Client und UiPath abgewickelt.

Die UiPath-Implementierung basiert auf der MCP-Protokollautorisierungsspezifikation Version 2025-11-28.

Übersicht über den Autorisierungsflow

Wenn sich ein MCP-Client mit einem UiPath-MCP-Server verbindet, läuft der Autorisierungsablauf wie folgt ab:

• Der Client ruft das Metadatendokument für geschützte Ressourcen des Servers ab.
• Die Metadaten identifizieren die erforderlichen OAuth-Scopes und den entsprechenden Autorisierungsserver.
• Der Client ruft die Metadaten des OAuth-Autorisierungsservers ab.
• Basierend auf den angekündigten Funktionen stellt der Client seine Identität mithilfe einer Dynamischen Clientregistrierung (DCR) oder eines Client ID Metadata Document (CILD) fest.
• Der Benutzer wird zu UiPath Cloud weitergeleitet, um sich anzumelden und seine Zustimmung zu erteilen.
• Der Client tauscht den resultierenden Autorisierungscode gegen OAuth-Token aus.
• Der Client verwendet das Zugriffstoken, um den MCP-Server aufzurufen, und aktualisiert das Token bei Bedarf.

Automatische Client-Registrierung (CILD und DCR)

UiPath unterstützt zwei sich ergänzende Mechanismen zur Ermittlung der OAuth-Identität eines MCP-Clients: Dynamische Client-Registrierung und Metadatendokumente der Client-ID. Beide Funktionen werden über die Metadaten des OAuth-Autorisierungsservers angegeben, sodass kompatible Clients den entsprechenden Mechanismus auswählen können, ohne dass eine manuelle Konfiguration erforderlich ist.

Dynamische Client-Registrierung

Dynamische Client-Registrierung (DCR), definiert durch RFC 7591, ermöglicht es einem MCP-Client, sich programmgesteuert zu registrieren. Der Client übermittelt seine Metadaten an den UiPath /oauth/register -Endpunkt, der den Anzeigenamen des Clients, Umleitungs-URIs, unterstützte Gewährungs- und Antworttypen sowie andere vom Autorisierungsserver erforderliche Metadaten enthalten kann.

Wenn die Registrierungsanforderung akzeptiert wird, gibt UiPath ein client_id zurück, das den registrierten Client während des gesamten Autorisierungsablaufs darstellt. UiPath überträgt und validiert die Clientidentität während der nachfolgenden Schritte zur Autorisierung, zum Tokenaustausch und zur Tokenaktualisierung erneut.

DCR ist für Clients geeignet, die die Registrierung dynamisch initiieren können, aber kein stabiles, öffentlich zugängliches Metadatendokument hosten können.

Die dynamische Client-Registrierung gilt als veraltet und als Legacy-Fallback in der MCP-Spezifikation. Sie wird in Zukunft entfernt.

Metadatendokumente zur Client-ID

Client ID Metadata Documents (CILD) bieten eine registrierungsfreie Alternative. Bei CILD verwendet der Client eine HTTPS-URL als client_id. Die URL verweist auf ein Metadatendokument, das den Client beschreibt, einschließlich seiner Umleitungs-URIs und anderer genehmigungsbezogener Eigenschaften.

Zum Zeitpunkt der Autorisierung ruft UiPath das Metadatendokument von der angegebenen URL ab und validiert seinen Inhalt. Dieser Ansatz hat mehrere Vorteile:

• Es ist keine separate Registrierungsanforderung erforderlich.
• UiPath muss keinen persistenten Registrierungsdatensatz für den Client pflegen.
• Die aktuellen Metadaten des Clients können abgerufen und validiert werden, wenn die Autorisierung erfolgt.
• Der Client muss seine Metadaten an einem stabilen HTTPS-Speicherort hosten.

CILD ist besonders geeignet für Kunden, die ein stabiles, öffentlich zugängliches Metadatendokument veröffentlichen können und eine separate OAuth-Client-Registrierung vermeiden möchten.

Konfiguration des AI Trust Layer

Der MCP OAuth-Proxy-Flow wird von einer AI Trust Layer (AITL)-Konfiguration gesteuert, die AgentHub von der Automation Ops Governance für das agierende Paar (Benutzer, Mandant) auflöst. Es dient zwei Zwecken:

• Funktionsaktivierung: Der Richtlinienumschalter „mcp-dynamic-clients“ steuert, ob die automatische Clientregistrierung zulässig ist. AgentHub bewertet es in drei Punkten neu – Zustimmung, Tokenaustausch und Tokenaktualisierung. Der Flow wird bei Fehler geschlossen: Wenn sich die aufgelöste Richtlinie nicht explizit anmeldet (mcp-dynamic-clients = true), wird die Anfrage blockiert und dem Benutzer wird eine Seite mit einem Link zum AITL Governance-Administrator angezeigt, auf der die Funktion aktiviert werden kann.
• Zulassungsliste für Rückrufdomänen: Organisationen können pro Organisation eine Zulassungsliste von Rückrufdomänen (Umleitungsdomänen) definieren, für die Autorisierungscodes übermittelt werden können. MCP-Server überprüfen alle Umleitungs-URIs vor der Autorisierung anhand dieser Zulassungsliste. Diese mehrstufige Kontrolle in Kombination mit dem vorhandenen Governance-Gateway stellt sicher, dass Administratoren eine detaillierte Kontrolle darüber haben, wohin Autorisierungscodes gesendet werden. Umleitungs-URIs werden zusätzlich aus Sicherheitsgründen validiert: HTTPS ist erforderlich, es sei denn, der Host ist ein Loopback, interne IP-Hosts werden abgelehnt und Fragmente oder Benutzerinformationen sind nicht zulässig.

Ressourcenbindung und Scope

MCP-OAuth-Sitzungen sind an den spezifischen MCP-Server gebunden, für den sie mithilfe von RFC 8707-Ressourcenindikatoren autorisiert wurden. Dies bedeutet, dass ein Token, das für einen Server ausgestellt wurde, von anderen Servern abgelehnt wird, was eine zusätzliche Sicherheitsebene darstellt. Einige MCP-Clients (z. B. Microsoft Copilot) unterstützen noch keine Ressourcenbindung und greifen ordnungsgemäß auf mandantenbezogene Sitzungen zurück, bei denen eine einzige Autorisierung Zugriff auf alle MCP-Server innerhalb des Mandanten gewährt.

Unterstützte Clients

Die Authentifizierung des UiPath-MCP-Servers ist vollständig konform mit der MCP-Spezifikation.

Alternative Authentifizierung: Clients, die den MCP-OAuth-Flow noch nicht vollständig unterstützen, können sich mit persönlichen Zugriffstoken, externen Anwendungen oder Interaktiver Anmeldung authentifizieren.

Eine Anleitung zur Auswahl der richtigen Authentifizierungsmethode finden Sie unter MCP Server-Authentifizierung.