Skip to main content
現在ワークフローを実行しているユーザーの SSO ID を、そのワークフローが呼び出す下流の MCP サーバー へ転送します。これにより MCP サーバーは、すべての Dify リクエストを同一の固定アカウントとして扱うのではなく、実際のエンドユーザーとして動作できます（ユーザー単位の認可、監査、データスコープの制御）。
これは SSO 認証 と MCP ツール を基盤とするエンタープライズ機能です。あなたのアイデンティティプロバイダー（IdP）と MCP サーバーはブラックボックスとして扱います。本ページでは、それらが提供すべき要件のみを記載します。

​
仕組み

ワークフローが MCP サーバー上のツールを呼び出すとき、Dify は通常、MCP プロバイダーに設定された固定のワークスペースレベルの認証情報を1つ使って呼び出します。サーバーから見ると、すべての呼び出し元が同じ ID に見えます。 ID 転送を有効にすると、Dify は各送信リクエストにユーザー単位のトークン（IdP が実行中のユーザーに対して既に発行したもの）を追加で付与します。Dify が独自にトークンを署名・発行することはありません。IdP が発行し、あなたの MCP サーバーにスコープされたトークンを中継するだけで、MCP サーバーはそれを同じ IdP で検証します。 トークンは専用の HTTP ヘッダーに載せて送られるため、プロバイダーに既に設定されている認証情報を妨げることはありません。
核心となる考え方：MCP サーバーと Dify は同じ IdP を信頼する。

​
適用範囲

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

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

すでに IdP を Dify SSO に接続済みのはずです。転送を機能させるには、その同じ IdP が以下を満たす必要があります。新しい IdP や追加サービスは不要です。
  1. 共有 issuer。 Dify ユーザーを認証する IdP は、MCP サーバーが信頼する IdP と同一でなければなりません。両者ともその issuer に対してトークンを検証します。
  2. プロトコルは OIDC または OAuth2。 SAML はサポートされません。
  3. IdP がログイン時に refresh token を返す。 これが転送が依存する唯一の能力です。有効化の方法は IdP によって異なります。
  4. audience の合意。 Dify は、ユーザー単位の各トークンの aud をあなたの MCP サーバーにスコープするよう IdP に要求します。多くの IdP はデフォルトでこれを行わず、代わりに audience を SSO クライアントの識別子に設定します。両者が期待値について合意している限り、どちらでも問題ありません。いずれかを選んでください。
    • IdP を設定して audience を MCP サーバーにバインドする、または
    • （最も簡単） MCP サーバーが SSO のクライアント識別子を期待する audience として受け入れる。
    どちらを選んでも、MCP サーバーは audience を必ず検証しなければなりません。さもないと、その IdP が信頼する任意のトークンが MCP サーバーを呼び出せてしまいます。
その他（リダイレクト 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 サーバーが上記の要件を満たしたら、機能を有効化します。
1

OIDC または OAuth2 SSO を設定する

管理コンソールで、ワークスペースの SSO を OIDC または OAuth2 として設定します（SAML 不可）。SSO 認証の設定 をご覧ください。SSO 設定の変更は即座に反映され、再起動は不要です。
2

データベースマイグレーションを適用する

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

各ユーザーに一度 SSO でサインインしてもらう

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

MCP プロバイダーごとに転送をオンにする

ツール → MCP に移動し、プロバイダーを選択して 編集 をクリックし、ユーザー ID を転送 トグルを有効にして保存します。このトグルは、サインインに SSO が適用されている場合のみ表示されます（コミュニティ版や SSO が未設定の場合は非表示）。トグルは プロバイダー単位 であり、どの MCP サーバーに呼び出し元の ID を渡すかを管理者が一箇所で決定します。
5

検証する

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

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

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

​
事前チェックリスト

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