I have searched the existing issues and discussions.
Problem Description
I want to attach a server Tool server with an OpenAPI spec that uses HTTP Basic Auth, but Open WebUI currently only supports Bearer auth with a custom token or from the login itself.
Desired Solution you'd like
Add HTTP Basic Auth besides Bearer and Session for Managed Tool servers with OpenAPI spec.
Alternatives Considered
I could try to convert a Bearer token to HTTP Basic auth, but this would require middleware that either reads username and password from the token or has some kind of state. Both isn't an ideal solution.
Originally created by @b-eyselein on GitHub (May 19, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/14041
Originally assigned to: @tjbck on GitHub.
### Check Existing Issues
- [x] I have searched the existing issues and discussions.
### Problem Description
I want to attach a server Tool server with an OpenAPI spec that uses HTTP Basic Auth, but Open WebUI currently only supports `Bearer` auth with a custom token or from the login itself.
### Desired Solution you'd like
Add HTTP Basic Auth besides `Bearer` and `Session` for Managed Tool servers with OpenAPI spec.
### Alternatives Considered
I could try to convert a Bearer token to HTTP Basic auth, but this would require middleware that either reads username and password from the token or has some kind of state. Both isn't an ideal solution.
### Additional Context
The main function to change is [`get_tool_server_data(token: str, url: str) -> Dict[str, Any]` in `backend/open_webui/utils/tools.py`](https://github.com/open-webui/open-webui/blob/e6afa69f59295d2930ff57285d0933e207d8e4c3/backend/open_webui/utils/tools.py#L443). We'd need to pass a `BasicAuth` to this function and to the call `session.get(url, ...)` with an additional parameter `auth=BasicAuth(username, password)`. Depending on the SQL table columns an additional row could be needed.
After starting to use the Tool servers, this immediately came into need for us as well.
<!-- gh-comment-id:2902500153 -->
@Lutherwaves commented on GitHub (May 22, 2025):
After starting to use the Tool servers, this immediately came into need for us as well.
If I may add to that, modifying the Bearer prefix to a free text field – or perhaps a combination of a dropdown selection and a free text input – could allow us to utilize APIs that do not support the Bearer option.
For example, Paperless-ngx expects either the Token or Basic prefix for the Authorization header, as documented here: https://docs.paperless-ngx.com/api/
If you consider this too off topic, @b-eyselein, please let me know and I'll create a new issue. Don't want to hijack your topic, but I felt it fits.
<!-- gh-comment-id:2908025558 -->
@tedstriker commented on GitHub (May 25, 2025):
If I may add to that, modifying the `Bearer` prefix to a free text field – or perhaps a combination of a dropdown selection and a free text input – could allow us to utilize APIs that do not support the `Bearer` option.
For example, Paperless-ngx expects either the `Token` or `Basic` prefix for the Authorization header, as documented here: https://docs.paperless-ngx.com/api/
If you consider this too off topic, @b-eyselein, please let me know and I'll create a new issue. Don't want to hijack your topic, but I felt it fits.
Your comment isn't off topic, but great input. The way I see it you have at least three different login options that a client would need to support:
Using the Open WebUI token ("Session", currently supported)
Bearer auth (e.g. with a Json Web Token, currently supported)
HTTP Basic Auth with username and password
These options need no, a single or two additional fields for login information. The svelte UI currenlty handles the first two, adding the third in the UI shouldn't be a big problem. Maybe another method "Custom" where you can put in the complete value that is send in the Authorization header can cover more exotic cases.
I see more work coming in in the backend where you need to check in multiple places which of these methods is requested.
<!-- gh-comment-id:2908714881 -->
@b-eyselein commented on GitHub (May 26, 2025):
Your comment isn't off topic, but great input. The way I see it you have at least three different login options that a client would need to support:
- Using the Open WebUI token ("Session", currently supported)
- Bearer auth (e.g. with a Json Web Token, currently supported)
- HTTP Basic Auth with username and password
These options need no, a single or two additional fields for login information. The svelte UI currenlty handles the first two, adding the third *in the UI* shouldn't be a big problem. Maybe another method "Custom" where you can put in the complete value that is send in the `Authorization` header can cover more exotic cases.
I see more work coming in in the backend where you need to check in multiple places which of these methods is requested.
@JasperMeyerInPro commented on GitHub (May 26, 2025):
Also, a separate auth method for the OpenAPI document itself would be nice.
I use the session token and validate it against the OpenWebUI Auth Api from my backend whhere I also get the user's email from.
If I protect the OpenAPI document with that auth handler, saving the tool server configuration works but not actually using it because in the chat it's just not there.
If this could be a bug, I'd open a new issue but if it is just not planned a separate auth would be nice.
Edit: I found when refreshing the chat page the backend makes a call to the open API document but does not send the user token.
<!-- gh-comment-id:2910293674 -->
@JasperMeyerInPro commented on GitHub (May 26, 2025):
Also, a separate auth method for the OpenAPI document itself would be nice.
I use the session token and validate it against the OpenWebUI Auth Api from my backend whhere I also get the user's email from.
If I protect the OpenAPI document with that auth handler, saving the tool server configuration works but not actually using it because in the chat it's just not there.
If this could be a bug, I'd open a new issue but if it is just not planned a separate auth would be nice.
Edit: I found when refreshing the chat page the backend makes a call to the open API document but does not send the user token.
I'm going to start playing around with this a bit myself and will report back.
<!-- gh-comment-id:2968715953 -->
@spockNinja commented on GitHub (Jun 13, 2025):
Along these same lines, I am trying to integrate an OpenAPI spec that uses the `apiKey` Header. (Adding the auto-generated supabase API!)
According to [these docs](https://swagger.io/docs/specification/v3_0/authentication/), there are several potential ways secure an API. The more we support, the better.
Besides the code mentioned above, I found a few other spots that would need updating.
[verify_tool_servers_config](https://github.com/open-webui/open-webui/blob/63256136ef8322210c01c2bb322097d1ccfb8c6f/backend/open_webui/routers/configs.py#L117)
[executeToolServer](https://github.com/open-webui/open-webui/blob/63256136ef8322210c01c2bb322097d1ccfb8c6f/src/lib/apis/index.ts#L377)
I'm going to start playing around with this a bit myself and will report back.
I think the most easy and at the same time broadest approach would be, to allow adding custom headers and their values to requests. This way, many use cases can be addressed.
It would solve token based API authentications as well as the initially requested Basic Auth in one go.
Just something like that:
Admittedly, this is rather technical than user friendly, but honestly, to configure tool servers for a self hosted LLM frontend, I'd assume the person doing this is already techsavvy enough.
<!-- gh-comment-id:2993992998 -->
@tedstriker commented on GitHub (Jun 22, 2025):
I think the most easy and at the same time broadest approach would be, to allow adding custom headers and their values to requests. This way, many use cases can be addressed.
It would solve token based API authentications as well as the initially requested Basic Auth in one go.
Just something like that:
<img width="817" alt="Image" src="https://github.com/user-attachments/assets/1e516074-5b42-4e94-ba40-024be68530ff" />
Admittedly, this is rather technical than user friendly, but honestly, to configure tool servers for a self hosted LLM frontend, I'd assume the person doing this is already techsavvy enough.
@tjbck apologies if I missed this, but which version implements this?
<!-- gh-comment-id:3732477425 -->
@Lutherwaves commented on GitHub (Jan 10, 2026):
@tjbck apologies if I missed this, but which version implements this?
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @b-eyselein on GitHub (May 19, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/14041
Originally assigned to: @tjbck on GitHub.
Check Existing Issues
Problem Description
I want to attach a server Tool server with an OpenAPI spec that uses HTTP Basic Auth, but Open WebUI currently only supports
Bearerauth with a custom token or from the login itself.Desired Solution you'd like
Add HTTP Basic Auth besides
BearerandSessionfor Managed Tool servers with OpenAPI spec.Alternatives Considered
I could try to convert a Bearer token to HTTP Basic auth, but this would require middleware that either reads username and password from the token or has some kind of state. Both isn't an ideal solution.
Additional Context
The main function to change is
get_tool_server_data(token: str, url: str) -> Dict[str, Any]inbackend/open_webui/utils/tools.py. We'd need to pass aBasicAuthto this function and to the callsession.get(url, ...)with an additional parameterauth=BasicAuth(username, password). Depending on the SQL table columns an additional row could be needed.@Lutherwaves commented on GitHub (May 22, 2025):
After starting to use the Tool servers, this immediately came into need for us as well.
@tedstriker commented on GitHub (May 25, 2025):
If I may add to that, modifying the
Bearerprefix to a free text field – or perhaps a combination of a dropdown selection and a free text input – could allow us to utilize APIs that do not support theBeareroption.For example, Paperless-ngx expects either the
TokenorBasicprefix for the Authorization header, as documented here: https://docs.paperless-ngx.com/api/If you consider this too off topic, @b-eyselein, please let me know and I'll create a new issue. Don't want to hijack your topic, but I felt it fits.
@b-eyselein commented on GitHub (May 26, 2025):
Your comment isn't off topic, but great input. The way I see it you have at least three different login options that a client would need to support:
These options need no, a single or two additional fields for login information. The svelte UI currenlty handles the first two, adding the third in the UI shouldn't be a big problem. Maybe another method "Custom" where you can put in the complete value that is send in the
Authorizationheader can cover more exotic cases.I see more work coming in in the backend where you need to check in multiple places which of these methods is requested.
@JasperMeyerInPro commented on GitHub (May 26, 2025):
Also, a separate auth method for the OpenAPI document itself would be nice.
I use the session token and validate it against the OpenWebUI Auth Api from my backend whhere I also get the user's email from.
If I protect the OpenAPI document with that auth handler, saving the tool server configuration works but not actually using it because in the chat it's just not there.
If this could be a bug, I'd open a new issue but if it is just not planned a separate auth would be nice.
Edit: I found when refreshing the chat page the backend makes a call to the open API document but does not send the user token.
@spockNinja commented on GitHub (Jun 13, 2025):
Along these same lines, I am trying to integrate an OpenAPI spec that uses the
apiKeyHeader. (Adding the auto-generated supabase API!)According to these docs, there are several potential ways secure an API. The more we support, the better.
Besides the code mentioned above, I found a few other spots that would need updating.
verify_tool_servers_config
executeToolServer
I'm going to start playing around with this a bit myself and will report back.
@tedstriker commented on GitHub (Jun 22, 2025):
I think the most easy and at the same time broadest approach would be, to allow adding custom headers and their values to requests. This way, many use cases can be addressed.
It would solve token based API authentications as well as the initially requested Basic Auth in one go.
Just something like that:
Admittedly, this is rather technical than user friendly, but honestly, to configure tool servers for a self hosted LLM frontend, I'd assume the person doing this is already techsavvy enough.
@Lutherwaves commented on GitHub (Jan 10, 2026):
@tjbck apologies if I missed this, but which version implements this?