Open WebUI Community Reports an MCP Authorization Selection Gap: Configured Secrets May Still Not Be Sent as Client Credentials

A new compatibility issue has been reported for Open WebUI’s remote tool integration. An issue filed on October 21 says that when connecting to an MCP service using OAuth 2.1 (Static), the program may choose an authentication method that does not send client credentials—even when an administrator has entered a client ID and client secret. As a result, users may complete the consent screen but get stuck during the authorization code exchange. The reporter lists v0.12.3 and the development branch at the time as affected environments. Issue and reproduction steps

The problem centers on the fallback logic for choosing an authentication method: the program first selects client_secret_post; if the server does not support it, the program takes the first method in the supported list. The X Ads authorization server in the report lists ["none", "client_secret_basic"], so the program selects none. The exchange request then omits client authentication and is rejected by the server. The reporter suggests that when a secret is configured, the program should prioritize Basic authentication if the server supports it. This remains a proposed change in the issue, not a released fix. Code analysis in the report

From a protocol perspective, RFC 8414 defines this field as a list of authentication methods supported by the token endpoint; it does not assign preference to the first entry. If the field is omitted, the default is client_secret_basic. The engineering requirement is to make the selected method compatible with the registered client’s credentials, rather than deciding solely based on array position. OAuth Authorization Server Metadata specification

For agent tool deployments, this means that “finding the authorization server” and “completing tool authorization” must be validated separately. The official documentation says Static mode uses pre-established credentials, while the OAuth discovery check on the settings page only confirms that the discovery document can be retrieved and parsed; it does not list or call tools. A successful check therefore does not by itself prove that the integration works. Official MCP documentation

Operators can first check the methods advertised by the server, the method actually selected, and any callback errors, then track whether upstream adds credential-aware selection and regression tests. At the time of review, the issue had only an automated linked-issue response, with no visible human confirmation or linked fix. The available evidence supports a failure in a specific authorization flow; it does not show that all MCP connections are affected.