MCP OAuth フローを使用した認証

MCP 認可仕様を実装している MCP クライアントは、OAuth 2.0 を介して自動的に UiPath で認証できます。クライアントは、認可サーバーの検出を実行し、OAuth ID をプロビジョニングして、トークンを取得し、必要に応じて更新します。ユーザーと管理者は、OAuth アプリケーションを作成したり、アクセス トークンを手動で管理したりする必要はありません。

ユーザー側では、ブラウザーで UiPath Cloud にログインするだけです。クライアントのプロビジョニング、トークンの発行、トークンの更新は、クライアントと UiPath の間で処理されます。

UiPath の実装は、MCP プロトコル認可仕様バージョン 2025-11-28 に基づいています。

認可フローの概要

MCP クライアントが UiPath MCP サーバーに接続すると、認可フローは次のように続行されます。

• クライアントは、サーバーの保護されたリソース メタデータ ドキュメントを取得します。
• メタデータにより、必要な OAuth スコープと適切な承認サーバーが識別されます。
• クライアントが OAuth 承認サーバーのメタデータを取得します。
• アドバタイズされた機能に基づいて、クライアントは動的クライアント登録 (DCR) またはクライアント ID メタデータ ドキュメント (CIMD) を使用して ID を確立します。
• ユーザーは UiPath Cloud にリダイレクトされ、サインインして同意します。
• クライアントは、生成された認可コードを OAuth トークンと交換します。
• クライアントはアクセス トークンを使用して MCP サーバーを呼び出し、必要に応じてトークンを更新します。

自動クライアント登録 (CIMD および DCR)

UiPath では、MCP クライアントの OAuth ID を確立するために、動的クライアント登録とクライアント ID メタデータ ドキュメントという 2 つの補完的なメカニズムをサポートしています。どちらの機能も OAuth 認可サーバー メタデータを介してアドバタイズされるため、対応するクライアントは手動で設定することなく適切なメカニズムを選択できます。

動的クライアント登録

RFC 7591 で定義されている動的クライアント登録 (DCR) を使用すると、MCP クライアントはプログラムによって自身を登録できます。クライアントは、そのメタデータを UiPath /oauth/register エンドポイントに送信します。このメタデータには、クライアントの表示名、リダイレクト URI、サポートされている付与と応答の種類、認可サーバーで必要なその他のメタデータが含まれます。

登録要求が受け入れられると、UiPath は承認フロー全体を通じて登録済みクライアントを表す client_id を返します。UiPath は、後続の認可、トークン交換、およびトークン更新の手順で、クライアント ID を保持し、再検証します。

DCR は、登録を動的に開始できるが、安定したパブリック アクセス可能なメタデータ ドキュメントをホストできないクライアントに適しています。

動的クライアント登録は非推奨と見なされ、MCP 仕様ではレガシ フォールバックです。今後削除される予定です。

クライアント ID メタデータ ドキュメント

クライアント ID メタデータ ドキュメント (CIMD) は、登録不要の代替手段です。CIMD では、クライアントは HTTPS URL を client_idとして使用します。この URL は、リダイレクト URI やその他の認可関連のプロパティなど、クライアントを記述するメタデータ ドキュメントを指します。

認可時に、UiPath は指定された URL からメタデータ ドキュメントを取得し、その内容を検証します。このアプローチにはいくつかの利点があります。

• 別途登録申請は不要です。
• UiPath は、クライアントに対して永続的な登録レコードを維持する必要はありません。
• クライアントの現在のメタデータは、認可の発生時に取得して検証できます。
• クライアントは、メタデータを安定した HTTPS の場所でホストする必要があります。

CIMD は、安定したパブリック アクセス可能なメタデータ ドキュメントを公開でき、個別の OAuth クライアント登録の維持を回避したいクライアントに特に適しています。

AI Trust Layer の設定

MCP の OAuth プロキシ フローは、AI Trust Layer (AITL) の設定によって管理されます。これは、動作する (ユーザー、テナント) ペアに対して AgentHub が Automation Ops のガバナンスから解決します。これには次の 2 つの目的があります。

• 機能の有効化: mcp-dynamic-clients ポリシーのトグルは、クライアントの自動登録を許可するかどうかを制御します。AgentHub は、同意、トークンの交換、トークンの更新の 3 つのポイントで再評価します。フローはフェイルクローズされます。解決されたポリシーが明示的にオプトインしない限り (mcp-dynamic-clients = true)、要求はブロックされ、この機能を有効化できる AITL ガバナンス管理者へのリンクページがユーザーに表示されます。
• コールバック ドメイン許可リスト: 組織は、認可コードを配信できるコールバック (リダイレクト) ドメインの組織ごとの許可リストを定義できます。MCP サーバーは、認可前にすべてのリダイレクト URI をこの許可リストに対して検証します。この階層化された制御を既存のガバナンス ゲートと組み合わせることで、管理者は認可コードの送信先をきめ細かく制御できます。リダイレクト URI は安全性のためにさらに検証されています: HTTPS は、ホストがループバックされ、内部 IP ホストが拒否され、フラグメントやユーザー情報が許可されていない場合に限り必要です。

リソースのバインドとスコープ

MCP OAuth セッションは、RFC 8707 リソース インジケーターを使用して承認された特定の MCP サーバーにバインドされます。これは、あるサーバーに対して発行されたトークンが他のサーバーによって拒否され、追加のセキュリティ層が提供されることを意味します。一部の MCP クライアント (Microsoft Copilot など) は、リソース バインドをまだサポートしておらず、テナント スコープのセッションにスムーズにフォールバックします。このセッションでは、1 つの認可でテナント内のすべての MCP サーバーへのアクセス権が付与されます。

サポートされているクライアント

UiPath MCP サーバーの認証は、MCP 仕様に完全に準拠しています。

代替認証: MCP OAuth フローをまだ完全にはサポートしていないクライアントの場合は、 個人用アクセス トークン、 外部アプリケーション、または 対話型ログインを使用して認証できます。

適切な認証方法を選択するためのガイダンスについては、「 MCP サーバーの認証」をご覧ください。