Dify 社群提出 MCP 授權修補，修改伺服器名稱可能覆寫 OAuth 用戶端識別碼

Dify 的 MCP 整合出現設定更新與授權狀態保存不一致的社群回報。10 月 31 日建立的議題指出，在 Docker 自架版 1.18.0 中，透過 Keycloak 完成動態用戶端註冊（DCR）並成功取得工具後，只要回頭修改 MCP 伺服器名稱等參數、儲存再重新授權，就可能收到找不到用戶端的錯誤。回報附有授權網址與日誌，其中 client_id 已變成帶星號的遮蔽字串。問題回報

修補作者追查指出，編輯介面會將遮蔽後的識別碼與密鑰送回後端；合併邏輯卻從已存憑證的頂層尋找原值，而實際資料位於巢狀的 client_information。查找失敗後，遮蔽字串便可能覆寫原本識別碼。PR #45211 改用既有讀取介面取回用戶端資訊，也處理解密後的密鑰。修補說明

討論還揭露第二層問題：即使保住識別碼，後續憑證重建仍可能丟棄存取權杖、更新權杖與 DCR 中繼資料。參與審查者因此要求測試完整的設定更新入口；作者隨後補上回歸測試，並表示已讓實際憑證未變時跳過重建。另一份 PR #45212 則提出偵測受損識別碼、重新動態註冊的復原路徑，仍屬待審方案。審查與修訂、另一修補方案

這類錯誤會影響代理連接外部工具的可靠性。MCP 的 2025-06-18 授權規格說明，HTTP 用戶端可透過 DCR 取得 OAuth 用戶端識別碼，並使用存取權杖呼叫受保護服務；因此，設定儲存流程也必須維持授權資料的一致性。MCP 授權規格

目前證據包含使用者重現步驟、日誌與修補討論，尚不能推定所有部署均受影響。工程團隊接下來應關注維護者審查、修補納入版本，以及已遭覆寫的設定能否安全復原；驗證時也應涵蓋「首次授權、僅改名稱、再次連線」的完整流程。