Open WebUI 社群回報 MCP 授權選擇缺口，已設密鑰仍可能不送出用戶端憑證

Open WebUI 的遠端工具整合出現新的相容性回報。10 月 21 日提交的議題指出，使用 OAuth 2.1（Static）連接 MCP 服務時，即使管理員填入 client ID 與 client secret，程式仍可能選擇不傳送用戶端憑證的驗證方式，讓使用者完成同意畫面後，卡在授權碼交換階段。回報者列出的環境為 v0.12.3 與當時的開發分支。議題與重現步驟

問題集中在驗證方式的退回邏輯：程式先選 client_secret_post，若伺服器不支援，便取支援清單的第一項。回報中的 X Ads 授權伺服器列出 ["none", "client_secret_basic"]，因此程式選到 none，交換請求未附用戶端驗證，遭伺服器拒絕。回報者建議，有密鑰時應優先選擇伺服器支援的 Basic 驗證；這仍是議題內的修改建議，尚非已發布修補。回報中的程式分析

從協定角度看，RFC 8414 將這個欄位定義為權杖端點支援的驗證方法清單，並未賦予第一項偏好順位；欄位省略時，預設才是 client_secret_basic。工程上的關鍵是讓選擇結果符合已註冊用戶端的憑證條件，不能僅依陣列位置決定。OAuth 伺服器中繼資料規範

這對代理工具部署的意義，是「找到授權伺服器」與「能完成工具授權」必須分開驗證。官方文件說明，Static 模式使用預先建立的憑證，而設定頁的 OAuth discovery 檢查只確認探索文件能被取得及解析，不會列出或呼叫工具。因此，檢查顯示成功仍不足以證明整合可用。官方 MCP 文件

維運者可先核對伺服器公布的方法、實際選用結果及回呼錯誤，再追蹤上游是否加入憑證感知的選擇與回歸測試。截至查核時，議題只有自動關聯回覆，未見人工確認或連結修補；現有證據支持特定授權流程失敗，不能推論所有 MCP 連線均受影響。