DifyコミュニティがMCP認証の修正を提案、サーバー名の変更でOAuthクライアントIDが上書きされる可能性

DifyのMCP連携で、設定更新と認証状態の保存に不整合があるとの報告がコミュニティから寄せられた。10月31日に作成されたIssueによると、Dockerのセルフホスト版1.18.0でKeycloakを通じた動的クライアント登録（DCR）を行い、ツールを正常に取得した後、MCPサーバー名などの設定を変更して保存し、再認証すると、「クライアントが見つからない」というエラーが返ることがある。報告には認証URLとログが添付されており、client_idがアスタリスクを含むマスク文字列に変わっていた。問題報告

修正の作成者による調査では、編集画面がマスク済みの識別子とシークレットをバックエンドに送り返していた。一方、マージ処理は保存済みの認証情報のトップレベルから元の値を探していたが、実際のデータはネストされたclient_informationに格納されていた。検索に失敗すると、マスク文字列が元の識別子を上書きする可能性がある。PR #45211では、既存の読み取りインターフェースを使ってクライアント情報を取得するよう変更し、復号後のシークレットも処理している。修正の説明

議論では、もう一つの問題も明らかになった。識別子を保持できても、その後の認証情報の再構築でアクセストークン、リフレッシュトークン、DCRメタデータが失われる可能性があった。レビュー参加者は、設定更新の入口から一連の処理をテストするよう求めた。これを受け、作成者は回帰テストを追加し、実際の認証情報に変更がない場合は再構築をスキップするようにしたと述べた。別のPR #45212では、破損した識別子を検知して動的に再登録する復旧手順が提案されているが、こちらも審査中だ。レビューと修正、別の修正案

この種の不具合は、エージェントが外部ツールに接続する際の信頼性に影響する。MCPの2025-06-18認可仕様では、HTTPクライアントがDCRを通じてOAuthクライアントIDを取得し、アクセストークンを使って保護されたサービスを呼び出せると説明されている。そのため、設定の保存処理でも認証データの整合性を保つ必要がある。MCP認可仕様

現時点の証拠は、ユーザーによる再現手順、ログ、修正をめぐる議論であり、すべてのデプロイ環境が影響を受けるとは断定できない。今後は、メンテナーによるレビュー、修正が取り込まれるバージョン、上書き済みの設定を安全に復旧できるかに注目したい。検証では「初回認証、名前だけを変更、再接続」という一連の流れも確認する必要がある。