Open WebUIコミュニティ、MCPの認可方式選択に不備を報告。秘密鍵を設定してもクライアント認証情報が送信されない可能性

Open WebUIのリモートツール連携で、新たな互換性に関する報告が寄せられた。10月21日に提出されたissueによると、OAuth 2.1（Static）でMCPサービスに接続する際、管理者がclient IDとclient secretを入力していても、プログラムがクライアント認証情報を送信しない認証方式を選ぶ場合がある。その結果、ユーザーが同意画面を完了した後、認可コードの交換段階で処理が止まる。報告者が挙げた環境はv0.12.3と当時の開発ブランチ。issueと再現手順

問題は認証方式のフォールバック処理にある。プログラムはまずclient_secret_postを選び、サーバーが対応していない場合は、対応方式リストの先頭を選ぶ。報告にあるX Adsの認可サーバーは["none", "client_secret_basic"]を公開しているため、プログラムはnoneを選択する。交換リクエストにはクライアント認証が含まれず、サーバーに拒否された。報告者は、secretが設定されている場合、サーバーが対応するBasic認証を優先すべきだと提案している。これはissue内の修正案であり、リリース済みの修正ではない。報告内のコード分析

プロトコルの観点では、RFC 8414はこのフィールドを、token endpointが対応する認証方式のリストとして定義しており、先頭項目に優先順位を与えてはいない。フィールドが省略された場合のデフォルトはclient_secret_basicである。実装上の要点は、配列内の位置だけで方式を決めるのではなく、選択結果を登録済みクライアントの認証情報の条件に適合させることだ。OAuthサーバーメタデータ仕様

これは、エージェントツールを導入する際、「認可サーバーを見つけられること」と「ツールの認可を完了できること」を分けて検証する必要があることを示している。公式ドキュメントによると、Staticモードでは事前に作成した認証情報を使用する。また、設定画面のOAuth discoveryチェックで確認するのは、discovery文書を取得して解析できるかどうかだけで、ツールの一覧表示や呼び出しは行わない。そのため、チェックが成功しても連携が利用可能だとは証明できない。公式MCPドキュメント

運用担当者は、サーバーが公開する方式、実際に選択された方式、コールバック時のエラーを確認したうえで、上流に認証情報を考慮した方式選択と回帰テストが追加されるか追跡できる。確認時点でissueにあるのは自動関連付けの返信のみで、メンテナーによる確認や修正へのリンクは見当たらない。現時点の証拠が示すのは特定の認可フローの失敗であり、すべてのMCP接続に影響すると結論づけることはできない。