本ページでは、転送を有効化する方法と、事前に必要な条件について説明します。信頼モデルや、アイデンティティプロバイダー / MCP サーバーに対する完全な要件については、MCP ユーザー ID 転送 をご覧ください。
前提条件
転送を有効化する前に、以下が満たされていることを確認してください。- エンタープライズ版で、ワークスペースに OIDC または OAuth2 SSO が設定されていること（SAML はサポートされません）。
- アイデンティティプロバイダーがログイン時に refresh token を発行すること。これにより、Dify は各ユーザーの呼び出しごとのトークンを取得できます。
- MCP サーバーが、転送されたトークンを同じアイデンティティプロバイダーで検証し、未認証のリクエストを拒否すること。
ここでは概要のみを示します。完全な要件（共有 issuer のルール、トークンの audience の扱い、MCP サーバーが検証すべき具体的な内容）については、MCP ユーザー ID 転送 の手順に従って設定してください。
転送を有効化する
OIDC または OAuth2 SSO を適用する
ワークスペースの SSO を OIDC または OAuth2 として設定・適用します。SSO 認証の設定 をご覧ください。
各ユーザーに一度 SSO でサインインしてもらう
Dify が後でユーザーに代わって呼び出しごとのトークンを取得できるよう、各ユーザーは少なくとも一度 SSO でサインインする必要があります。コンソール／ワークスペースのユーザーと、公開された Web App のエンドユーザーの両方が自動的に処理されます。
MCP プロバイダーのトグルをオンにする
ツール → MCP に移動し、プロバイダーを選択して 編集 をクリックし、ユーザー ID を転送 を有効にして保存します。このトグルは、サインインに SSO が適用されている場合のみ表示されます（コミュニティ版や SSO が未設定の場合は非表示）。トグルは プロバイダー単位 であり、どの MCP サーバーに呼び出し元の ID を渡すかを管理者が一箇所で決定します。
送信される呼び出しの変化
転送が有効な場合、Dify は MCP サーバーへの各リクエストに専用のヘッダーを追加します。これはプロバイダーに既に設定されている認証情報を置き換えるのではなく、併存します。Service API 呼び出しやスケジュール（Cron）実行はサポートされません。これらには対話的なユーザーが存在しないため、これらの実行経路で転送に依存しないでください。
トラブルシューティング
| 状況 | 対処 |
|---|---|
| 実行中のユーザーが一度も SSO でサインインしていない、またはセッションを更新できない | ユーザーに SSO で（再）サインインしてもらう |
| SSO が未設定または無効 | 管理コンソールで SSO を設定する |