> ## Documentation Index
> Fetch the complete documentation index at: https://enterprise-docs.dify.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP ユーザー ID 転送

**現在ワークフローを実行しているユーザー**の SSO ID を、そのワークフローが呼び出す下流の [MCP サーバー](/ja/3.11.x/use/workspace/tools) へ転送します。これにより MCP サーバーは、すべての Dify リクエストを同一の固定アカウントとして扱うのではなく、実際のエンドユーザーとして動作できます（ユーザー単位の認可、監査、データスコープの制御）。

<Note>
  これは [SSO 認証](/ja/3.11.x/administer/sso/introduction) と [MCP ツール](/ja/3.11.x/use/workspace/tools) を基盤とするエンタープライズ機能です。あなたのアイデンティティプロバイダー（IdP）と MCP サーバーはブラックボックスとして扱います。本ページでは、それらが提供すべき要件のみを記載します。
</Note>

## 仕組み

ワークフローが MCP サーバー上のツールを呼び出すとき、Dify は通常、MCP プロバイダーに設定された**固定のワークスペースレベルの認証情報**を1つ使って呼び出します。サーバーから見ると、すべての呼び出し元が同じ ID に見えます。

ID 転送を有効にすると、Dify は各送信リクエストに**ユーザー単位のトークン**（IdP が実行中のユーザーに対して既に発行したもの）を追加で付与します。Dify が独自にトークンを署名・発行することはありません。IdP が発行し、あなたの MCP サーバーにスコープされたトークンを中継するだけで、MCP サーバーはそれを**同じ IdP** で検証します。

トークンは専用の HTTP ヘッダーに載せて送られるため、プロバイダーに既に設定されている認証情報を妨げることはありません。

```
X-Dify-SSO-Token: <実行中のユーザーを表すトークン>
```

```
実行中のユーザー（SSO 認証済み）
        │  ID
        ▼
   Dify ワークフロー ──[ ユーザーの IdP トークン ]──▶ MCP サーバー
                                              │
                                              └─ 同じ IdP でトークンを検証
```

核心となる考え方：**MCP サーバーと Dify は同じ IdP を信頼する。**

### 適用範囲

| 呼び出し元                            | 転送   |
| -------------------------------- | ---- |
| ワークスペースユーザーがコンソールでワークフローを実行      | サポート |
| ワークスペースユーザーがアプリ経由で実行（チャットアプリを含む） | サポート |
| 公開された Web App のエンドユーザー           | サポート |
| Service API 呼び出し                 | 非対応  |
| スケジュール / Cron トリガー               | 非対応  |
| SAML SSO でサインインしたユーザー            | 非対応  |
| コミュニティ版（非エンタープライズ）デプロイ           | 利用不可 |

<Note>
  ID 転送は上記のサポート対象の呼び出し元にのみ適用されます。Service API 呼び出しやスケジュール（Cron）実行は**サポートされません**。これらには対話的なユーザーが存在しないため、これらの実行経路で ID 転送に依存しないでください。
</Note>

## アイデンティティプロバイダーに対する要件

すでに IdP を Dify SSO に接続済みのはずです。転送を機能させるには、その**同じ** IdP が以下を満たす必要があります。新しい IdP や追加サービスは不要です。

1. **共有 issuer。** Dify ユーザーを認証する IdP は、MCP サーバーが信頼する IdP と同一でなければなりません。両者ともその issuer に対してトークンを検証します。

2. **プロトコルは OIDC または OAuth2。** SAML はサポートされません。

3. **IdP がログイン時に refresh token を返す。** これが転送が依存する唯一の能力です。有効化の方法は IdP によって異なります。

   | IdP の種類                                                                     | 有効化すべき内容                                                                               |
   | --------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
   | 標準的な OIDC / OAuth2（Microsoft Entra ID、Okta、Auth0、Keycloak、Ping、OneLogin など） | クライアントで `offline_access` スコープを許可し、refresh-token グラントを有効にする。                            |
   | `offline_access` スコープ経由で refresh token を発行しない IdP（例：Google）                 | 管理者の操作は不要 — Dify が自動的に処理します。                                                           |
   | OAuth2 モードのクライアント                                                           | 設定済みのスコープ一覧に、refresh を付与するスコープ（`offline_access`、または Salesforce の `refresh_token`）を含める。 |

4. **audience の合意。** Dify は、ユーザー単位の各トークンの `aud` をあなたの MCP サーバーにスコープするよう IdP に要求します。多くの IdP はデフォルトでこれを行わず、代わりに audience を SSO クライアントの識別子に設定します。**両者が期待値について合意している**限り、どちらでも問題ありません。いずれかを選んでください。

   * IdP を設定して audience を MCP サーバーにバインドする、または
   * *（最も簡単）* MCP サーバーが SSO の**クライアント識別子**を期待する audience として受け入れる。

   <Warning>
     どちらを選んでも、MCP サーバーは audience を**必ず**検証しなければなりません。さもないと、その IdP が信頼する任意のトークンが MCP サーバーを呼び出せてしまいます。
   </Warning>

その他（リダイレクト URI、ユーザープロビジョニングなど）は既存の SSO 設定であり、変更はありません。

## MCP サーバーに対する要件

MCP サーバーはブラックボックスとして扱います。転送された ID を利用するには、以下を行う必要があります。これ以外の Dify からの呼び出し方は変わりません。

1. **転送ヘッダーを読み取る。** `X-Dify-SSO-Token` が存在する場合、それをエンドユーザートークンのベアラーとして扱います。
2. **IdP に対してトークンを検証する** — IdP（例：IdP が公開する署名鍵、またはトークンイントロスペクション）を用いて署名を検証します。
3. **issuer を検証する** — あなたの IdP と一致すること。
4. **audience を検証する** — 上で選んだ方式に一致すること。このチェックを省略してはいけません。
5. 標準のトークンクレーム（`sub`、`email` など）から、アプリケーションの必要に応じて**ユーザーを導出する**。
6. **未認証のリクエストを拒否する** — 有効なトークンがない場合に匿名アクセスへフォールバックしないこと。

## ID 転送を有効化する

IdP と MCP サーバーが上記の要件を満たしたら、機能を有効化します。

<Steps>
  <Step title="OIDC または OAuth2 SSO を設定する">
    管理コンソールで、ワークスペースの SSO を OIDC または OAuth2 として設定します（SAML 不可）。[SSO 認証の設定](/ja/3.11.x/administer/sso/introduction) をご覧ください。SSO 設定の変更は即座に反映され、再起動は不要です。
  </Step>

  <Step title="データベースマイグレーションを適用する">
    本リリースに付属するデータベースマイグレーションを適用します。既存の MCP プロバイダーには影響しません — 転送はデフォルトで無効です。
  </Step>

  <Step title="各ユーザーに一度 SSO でサインインしてもらう">
    Dify が後でユーザーに代わって呼び出しごとのトークンを取得できるよう、各ユーザーは少なくとも一度 SSO でサインインする必要があります。コンソール／ワークスペースのユーザーと、公開された Web App のエンドユーザーの両方が自動的に処理されます。
  </Step>

  <Step title="MCP プロバイダーごとに転送をオンにする">
    **ツール → MCP** に移動し、プロバイダーを選択して **編集** をクリックし、**ユーザー ID を転送** トグルを有効にして保存します。

    このトグルは、サインインに SSO が適用されている場合のみ表示されます（コミュニティ版や SSO が未設定の場合は非表示）。トグルは **プロバイダー単位** であり、どの MCP サーバーに呼び出し元の ID を渡すかを管理者が一箇所で決定します。
  </Step>

  <Step title="検証する">
    そのプロバイダーを呼び出す任意のワークフローを実行し、MCP サーバーが転送されたトークンを受け取り、それが実行中のユーザーを表していることを確認します。
  </Step>
</Steps>

## トラブルシューティング

サポート対象の呼び出し元で転送が機能しない場合は、以下を確認してください。

| 状況                                           | 対処                       |
| -------------------------------------------- | ------------------------ |
| 実行中のユーザーが一度も SSO でサインインしていない、またはセッションを更新できない | ユーザーに SSO で（再）サインインしてもらう |
| SSO が未設定または無効                                | 管理コンソールで SSO を設定する       |

## 事前チェックリスト

* ワークスペースの SSO が OIDC または OAuth2（SAML 不可）。
* IdP クライアントが refresh token を許可している（`offline_access` スコープ / refresh グラント。Google 系は自動）。
* audience のバインド方法を決めた（IdP がバインドする、または MCP サーバーが SSO クライアント識別子を受け入れる）。
* MCP サーバーが IdP トークン（署名、issuer、audience）を検証し、匿名リクエストを拒否する。
* データベースマイグレーションを適用済み。
* ユーザーが少なくとも一度 SSO でサインイン済み。
* 対象の MCP プロバイダーで **ユーザー ID を転送** が有効。