S’authentifier avec le flux MCP OAuth

Les clients MCP qui implémentent la spécification d’autorisation MCP peuvent s’authentifier automatiquement auprès d’UiPath via OAuth 2.0. Le client effectue la découverte du serveur d'autorisation, enregistre son identité OAuth, obtient les jetons et les actualise si nécessaire. Les utilisateurs et les administrateurs n'ont pas besoin de créer manuellement des applications OAuth ou de gérer les jetons d'accès.

Du côté de l'utilisateur, la seule étape manuelle consiste à se connecter à UiPath Cloud dans le navigateur. L'enregistrement du client, l'émission de jeton et l'actualisation du jeton sont gérés entre le client et UiPath.

L'implémentation d'UiPath est basée sur la version 2025-11-28 de la spécification d'autorisation du protocole MCP.

Présentation du flux d'autorisations

Lorsqu’un client MCP se connecte à un serveur UiPath MCP, le flux d’autorisation se déroule comme suit:

• Le client récupère le document Métadonnées des ressources protégées du serveur.
• Les métadonnées identifient les étendues OAuth requises et le serveur d’autorisation approprié.
• Le client récupère les métadonnées du serveur d’autorisation OAuth.
• En fonction des capacités annoncées, le client établit son identité à l’aide de l’enregistrement dynamique du client ou d’un document de métadonnées d’ID de client.
• L’utilisateur est redirigé vers UiPath Cloud pour se connecter et donner son consentement.
• Le client échange le code d'autorisation obtenu pour les jetons OAuth.
• Le client utilise le jeton d'accès pour invoquer le serveur MCP et actualise le jeton si nécessaire.

Enregistrement automatique des clients (CIMD et DCR)

UiPath prend en charge deux mécanismes complémentaires pour établir l’identité OAuth d’un client MCP: Enregistrement dynamique du client et Documents de métadonnées de l’ID client. Les deux fonctionnalités sont annoncées via les métadonnées du serveur d'autorisation OAuth, ce qui permet aux clients compatibles de sélectionner le mécanisme approprié sans nécessiter de configuration manuelle.

Enregistrement dynamique du client

L’enregistrement dynamique du client, défini par RFC 7591, permet à un client MCP de s’enregistrer par programmation. Le client soumet ses métadonnées au point de terminaison UiPath /oauth/register, qui peuvent inclure le nom complet du client, les URI de redirection, les types d'octroi et de réponse pris en charge et d'autres métadonnées requises par le serveur d'autorisation.

Si la demande d'enregistrement est acceptée, UiPath renvoie une client_id représentant le client enregistré tout au long du flux d'autorisation. UiPath transporte et révalide l’identité du client lors des étapes ultérieures d’autorisation, d’échange de jetons et d’actualisation de jeton.

DCR est approprié pour les clients qui peuvent initier l’enregistrement de manière dynamique, mais qui ne peuvent pas héberger un document de métadonnées stable et accessible au public.

L’enregistrement dynamique du client est considéré comme obsolète et comme une solution de secours héritée dans la spécification MCP. Elle sera supprimée à l’avenir.

Documents de métadonnées d’ID client

Les documents de métadonnées d’ID client fournissent une alternative sans enregistrement. Avec CIMD, le client utilise une URL HTTPS comme client_id. L'URL pointe vers un document de métadonnées qui décrit le client, y compris ses URI de redirection, ainsi que d'autres propriétés liées à l'autorisation.

Au moment de l'autorisation, UiPath récupère le document de métadonnées à partir de l'URL fournie et valide son contenu. Cette approche présente plusieurs avantages:

• Aucune demande d'inscription distincte n'est requise.
• UiPath n’a pas besoin de maintenir un enregistrement persistant pour le client.
• Les métadonnées actuelles du client peuvent être obtenues et validées lors de l'autorisation.
• Le client doit héberger ses métadonnées dans un emplacement HTTPS stable.

CIMD est particulièrement adapté aux clients qui peuvent publier un document de métadonnées stable et accessible au public et qui souhaitent éviter de maintenir un enregistrement de client OAuth distinct.

Configuration d’AI Trust Layer

Le flux de proxy OAuth MCP est régi par une configuration AI Trust Layer, qu’AgentHub résout à partir de la gouvernance Automation Ops pour la paire agissante (utilisateur, locataire). Elle sert deux objectifs:

• Activation de la fonctionnalité: le bouton bascule de stratégie MCP-dynamic-clients contrôle si l’enregistrement automatique des clients est autorisé. AgentHub la réévalue à trois points: le consentement, l’échange de jetons et l’actualisation du jeton. Le flux est fermé en cas d'échec: à moins que la stratégie résolue ne choisisse explicitement (MCP-dynamic-clients = true), la requête est bloquée et l'utilisateur voit une page renvoyant vers l'administrateur de gouvernance AITL où la fonctionnalité peut être activée.
• Liste d'autorisation des domaines de rappel: les organisations peuvent définir une liste d'autorisation par organisation de domaines de rappel (de redirection) où les codes d'autorisation peuvent être fourni. Les serveurs MCP valident tous les URI de redirection par rapport à cette liste d'autorisation avant l'autorisation. Ce contrôle étendu, combiné à la passerelle de gouvernance existante, garantit que les administrateurs disposent d'un contrôle précis sur l'envoi des codes d'autorisation. Les URI de redirection sont par ailleurs validés pour la sécurité: HTTPS est requis sauf si l’hôte est en bouclage, les hôtes d’IP interne sont rejetés et les fragments ou les informations utilisateur ne sont pas autorisés.

Liaison et étendue de la ressource

Les sessions OAuth MCP sont liées au serveur MCP spécifique pour lequel elles ont été autorisées à utiliser les indicateurs de ressources RFC 8707. Cela signifie qu'un jeton émis pour un serveur est rejeté par d'autres serveurs, offrant ainsi une couche de sécurité supplémentaire. Certains clients MCP (tels que Microsoft Copilot) ne prennent pas encore en charge la liaison des ressources et se replient sur des sessions à l'échelle du locataire où une seule autorisation accorde l'accès à tous les serveurs MCP au sein du locataire.

Clients pris en charge

L’authentification du serveur MCP UiPath est entièrement conforme à la spécification MCP.

Authentification alternative: pour les clients qui ne prennent pas encore entièrement en charge le flux MCP OAuth, vous pouvez vous authentifier à l’aide de jetons d’accès personnels, d’applications externes ou d’une connexion interactive.

Pour obtenir des conseils sur le choix de la bonne méthode d'authentification, consultez Authentification du serveur MCP.