mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-08 21:09:41 -05:00
[GH-ISSUE #19313] feat: User specific MCP headers #57503
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#57503
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @patrykkozuch on GitHub (Nov 20, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/19313
Check Existing Issues
Verify Feature Scope
Problem Description
I want to develop a MCP server for a service that does not support OAuth / is not integrated with OAuth yet and supports only Basic Auth. For now, MCP configuration in Open WebUI supports supplying only the global API token to the server (and starting from 0.6.37 other custom headers thanks to #18918 ). I'd like to allow each user to supply their own credentials to work with the service through MCP server.
Desired Solution you'd like
As a user, I'd like to be able to use my own API key (and preferably set custom headers) when enabling the globally configured MCP server as a tool in the conversation - something like the scope configuration that happens when you enable OAuth MCP server as a user.
Something like user valves, but for MCP / tools servers.
I know that there is a possibility for each user to configure their own tools server but:
Alternatives Considered
No response
Additional Context
No response
@tjbck commented on GitHub (Nov 20, 2025):
@patrykkozuch would
Authheader withBearerprefix be enough for your use case?@patrykkozuch commented on GitHub (Nov 20, 2025):
@tjbck Yes, it would be. Would be nice to be able to add another headers too, but that's not a must
@ctolon commented on GitHub (Nov 21, 2025):
This feature can be truly useful. In another product ex. LibreChat, custom headers can be sent dynamically for the MCP (the header keys to be sent are defined in the MCP Server connection section and when the user connects to the MCP Server, values are assigned to the designated placeholders. For example, if the Role placeholder corresponding to the X-Role header is defined as an input in the MCP connection section, each user can enters an input for themselves, and this placeholder value can be sent to the MCP along with the X-Role header).
This can be particularly useful if the MCP Server implementation requires deterministic input from the user.
@ctolon commented on GitHub (Nov 23, 2025):
Regarding to this issue I created a PR -> https://github.com/open-webui/open-webui/pull/19379
We need this feature organizationally, too. We use it not just for authentication, but especially for MCPs that connect to SQL databases, allowing us to select tables and DBs etc. as input.
As far as I have tested the implementation,. If you want, you can clone it and test whether it meets your needs @patrykkozuch
@patrykkozuch commented on GitHub (Nov 26, 2025):
@ctolon This is exactly what we need. Thank you very much for your work here, it would be great if this can make it to the next version!
@andrescabana86 commented on GitHub (Dec 16, 2025):
happy that I see this is in progress! :)
@patrykkozuch commented on GitHub (Jan 12, 2026):
@tjbck I know you were busy recently with version 0.7, since it has been released, can we have any progress with this? I'd like to help with getting this into OWUI
@cannontrodder commented on GitHub (Jan 20, 2026):
A plus one fom me - https://github.com/open-webui/open-webui/pull/19379 was closed due to no movement but that (or something like it) wou;d be a great feature to have.
@Philoso-Fish commented on GitHub (Jan 28, 2026):
I can only back this! This is a feature that is really urgent for several projects in our company.
@patrykkozuch commented on GitHub (Feb 2, 2026):
@Classic298 Maybe we could get your attention on this?
@Classic298 commented on GitHub (Feb 2, 2026):
I should not decide this,
and cannot.
@paolo-depa commented on GitHub (Feb 3, 2026):
+1!!
@flefevre commented on GitHub (Feb 9, 2026):
Hi everyone,
We also have a strong need for this feature. Specifically, our users want to use the MCP Legifrance tool to access French laws and jurisprudence. However, the access token for the MCP server is individual, which complicates deployment at scale.
Our ideal workflow would be:
Administrator-side: The Open WebUI administrator should be able to define the external tool (URL, description, etc.) and associate it with an assistant model.
User-side: The end user should be able to input their individual API key to access the Legifrance service.
This would allow organizations to centrally manage tool configurations while letting users securely provide their own credentials.
Looking forward to your thoughts or updates on this!
@DigdashQuentinLandi commented on GitHub (Feb 16, 2026):
Hi ! we have also a strong need for this !
--> https://github.com/open-webui/open-webui/pull/19379 was closed due to no movement but that (or something like it) would be a great feature to have.
@fpytloun commented on GitHub (Feb 16, 2026):
Also came to this feature request when implementing my memory system (https://github.com/fpytloun/mnemory) and thinking about how to handle user separation properly. There are 2 approaches where both would be great:
{ "X-User-Id": "${username}"}(probably easiest option and sufficient for me)@DigdashQuentinLandi commented on GitHub (Feb 17, 2026):
Both are okay for us too
@fpytloun commented on GitHub (Feb 17, 2026):
BTW I workarounded that by letting my MCP server pick
X-OpenWebUI-User-Emailheader and use that as user identifier.@patrykkozuch commented on GitHub (Feb 17, 2026):
The problem with using
X-OpenWebUI-User-Emailis that somebody can get unauthorized access to resources.Imagine a situation, where you have an external system (in our case it is an issue tracker) - somebody creates an account in the OpenWebUI, then change their email address - and has full access to admin account. Not mentioning that you can then call the MCP server directly with manually changed header.
@Classic298 commented on GitHub (Feb 17, 2026):
@patrykkozuch how does sending the email to the external issue tracker equate to also leaking the password or whatnot of the admin user?
@fpytloun commented on GitHub (Feb 17, 2026):
@patrykkozuch Yes, but only if user is allowed to change email address on it's own which in most organizations is not possible. Otherwise you have openwebui instance-wide bearer token to MCP server + header with user email address that user should not be able to change. If you have reverse proxy with auth, it also passing username/email, etc. headers to backend app that is supposed to trust it. Not saying it is ideal solution for this case.
@patrykkozuch commented on GitHub (Feb 17, 2026):
I didn't say it means leaking the admin password, but if the email is our only source of user identity, it can be spoofed to authenticate as other user, i.e. admin.
@patrykkozuch commented on GitHub (Feb 17, 2026):
As far as I remember, the user can edit their email in the open-webui and there is no check / flag / permission that disallows this. Or am I wrong?
@Classic298 commented on GitHub (Feb 17, 2026):
how do you even have the email as the only means of authentication? Is that even possible in vanilla Open WebUI? You HAVE TO HAVE a password or valid oauth.
and if you don't, that's if anything also configuration issue on your end. Email as of means for authentication is not secure
@patrykkozuch commented on GitHub (Feb 17, 2026):
I have OpenWebUI properly secured. The problem is that from the perspective of the MCP server, I need to somehow authenticate the user to external resources.
Right now I can only use instance level bearer token + user's email passed through header or the MCP server secured with OAuth. However, implementing MCP server with OAuth brings a lot of overhead.
The user's email passed through header cannot be trusted, as it can be changed by the user to any other.
The easiest way I see for the users to authenticate to the external resources is to pass their own API Key through header like they can do with external tool servers.
@icsy7867 commented on GitHub (Mar 2, 2026):
Watching this thread as it's exactly what I am wanting to do.
Ideally someone could configure the admin side to require:
Variables 1,2 and 3, and these could be referneced in the MCP config somehow, or could automatically be used with the ENV vars in the tool calls, or used in headers.
So on the admin side you would see something like:
Bearer ${VAR_1}for that MCP server. And then the end user has to set ${VAR_1} for that specific tool before it can be used.I tried something similar here:
https://openwebui.com/posts/user_secrets_vault_keyvalue_storage_ace28230
And while the ${{{LLM_SECRET_#}}} work when chatting with an LLM and processed correctly, the header authenticate appears to not be able to be used without modification to open-webui's source code AFAIK.
@Mottomi commented on GitHub (Mar 26, 2026):
Also need this feature; would be nice if the custom headers can be defined in the user's valves section
@icsy7867 commented on GitHub (Apr 2, 2026):
To the security aspect and using the openwebui email header I am using this, but since users can send email headers this is a bad solution.
I wrote a jira mcp server that also has a separate oauth2 client webserver, where a user authenticated to jira and then saves their access token and refresh token, and then encrypts these using a key + the users email address, so not even I can tell whose file is whose.
Then when a user authenticated and calls the mcp server from openwebui, I can use that email header to select the correct file/access token.
So this has the flaws listed above and I can only think of THREE ways to make this work....
1.) If running with docker or in k8s, the mcp server wont be externally accessible and only inside of said k8s or docker network.
2.) Use the admin bearer token. This is actually pretty simple. In the admin panel you can set a long auth bearer token, and then make sure the mcp server is checking/matching this. So you are still using the email header to authenticated the user, but the bearer token ensures that the requests are coming from trusted servers/sources.
3.) Not sure if this is possible, I havent looked at it. But there are several headers sent... email address, chat ID, etc.... it might be possible to use the open-webui and verify that the sent chat ID is active and matches the email address/user. But how annoying...
IDEALLY - IMO when creating an external tool/mcp server, as and admin you could set required and optional valves. If a user enables a specific external tool/mcp server and hasnt included the required valves they would get prompted to do so. These values would get mapped to header values, and perhaps a special/specific one for an author bearer token.
If you want to get fancy, it would be cool if that could be set from some GET or POST callback, so one could populate that token via a workflow.
@adopic commented on GitHub (Apr 8, 2026):
I think this is exactly what my team needs as well.
To make my current problem easier to understand, this is a summary of my use case:
Sign-in via Keycloak ->
JWT is generated by Keycloak ->
Open WebUI inserts that JWT per user in its HTTP requests to MCP Servers ->
MCP Servers have logic (via: JWT Token Verification) to validate the JWT tokens, thus enforcing Authorization per-tool
@adopic commented on GitHub (Apr 8, 2026):
+1
This is exactly what I'd like as well.
Per user JWT tokens being sent from Open WebUI to MCP Servers, where the MCP Server can then validate the JWT against whatever OAuth service granted Open WebUI the JWT token.
This would enable MCP Server authors fine-grained enforcement, where if a user does not have the authority to use tool "X", the MCP Server can enforce that.
@Tyrannius commented on GitHub (Apr 8, 2026):
Dito. I am trying to integrate a headless openclaude into OWUI . I dont want to use open-terminal, as it lacks the features and also allowes the user to mess around too much.
With openclaude I am explicitly allowing frontend agents to only use OWUI native/genuine tools, while backend (subagents) do their magic without letting the user know their featurelist.
I tried directconnection via OPENAI endpoint and also pipe (which never ever worked fully for me, and it seems for many other people here) . Pipe gets me a deadlock due to SSE (Pipe holds OWUI thread, hub calls OWUI API, OWUI can't respond) and directconnection leaks too many rights on folders etc. due to static JWT without proper tweaking as mentioned above.
so instead, I let openclaude access OWUIs postgres in read-only mount) and had to do the following:
ENABLE_FORWARD_USER_INFO_HEADERS=true — OWUI sends X-OpenWebUI-User-Id (immutable UUID) to whereever you need it. That was explained above.
Direct PostgreSQL access — Hub reads chats (i only tried with chats and the correspondings tools sofar) from OWUI's DB with
WHERE user_id = %son every query. File content from shared volume (read-only mount). No OWUI HTTP calls = no deadlock.Anti-spoofing — Hub has no external port (Docker-internal only) + requires x-hub-secret header on every request set in the connection UI formular. Only OWUI can reach it, only with the correct secret. (OPENCLAUDE_HUB_SECRET)
@garrettashcroft1231-max commented on GitHub (Apr 9, 2026):
Thanks for sharing this — I’m running into very similar issues.
On Wed, Apr 8, 2026, 10:28 PM Tyrannius @.***> wrote:
@paolo-depa commented on GitHub (Apr 27, 2026):
After monitoring this for so long, I'm moving to Onyx -> https://docs.onyx.app/overview/core_features/actions