github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-15 21:19:39 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #21134] feat: MCP Streamable HTTP: user identity headers not forwarded to MCP servers #19392

New Issue
Closed
opened 2026-04-20 01:49:07 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-20 01:49:07 -05:00
Owner
Copy Link

Originally created by @rpostulart on GitHub (Feb 3, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21134

Check Existing Issues

  • I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.

Verify Feature Scope

  • I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.

Problem Description

Description

When ENABLE_FORWARD_USER_INFO_HEADERS=true is set, OpenWebUI correctly forwards X-OpenWebUI-User-Email, X-OpenWebUI-User-Id, X-OpenWebUI-User-Name, and
X-OpenWebUI-User-Role headers to OpenAI-compatible API backends (e.g., LiteLLM). However, these headers are not forwarded to MCP Streamable HTTP tool
server connections.

Additionally, template variables like {{USER_EMAIL}} configured in MCP connection custom headers are sent as literal strings rather than being resolved
to the actual user's email.

Steps to Reproduce

  1. Set ENABLE_FORWARD_USER_INFO_HEADERS=true on the OpenWebUI container
  2. Configure an MCP Streamable HTTP tool server connection with custom headers: {"x-openwebui-user-id": "{{USER_EMAIL}}"}
  3. Make a tool call from a chat
  4. Inspect the headers received by the MCP server

Desired Solution you'd like

Expected Behavior

Either:

  • Option A: ENABLE_FORWARD_USER_INFO_HEADERS should also forward X-OpenWebUI-User-Email (and other user info headers) to MCP Streamable HTTP
    connections, OR
  • Option B: Template variables like {{USER_EMAIL}} in MCP custom headers should be resolved to the actual user's email address

Actual Behavior

  • No X-OpenWebUI-User-* headers are sent to MCP servers
  • {{USER_EMAIL}} in custom headers is sent as the literal string {{USER_EMAIL}}

Headers received by the MCP server:
x-openwebui-user-id: {{USER_EMAIL}} ← literal string, not resolved

Missing headers (compared to LiteLLM requests):
x-openwebui-user-email: (not present)
x-openwebui-user-name: (not present)
x-openwebui-user-role: (not present)

Use Case

We use AWS Bedrock AgentCore Gateway as an MCP server to provide Jira, Confluence, and Microsoft 365 tools. The gateway uses per-user OAuth tokens
(3-legged OAuth) scoped by user identity. Without user identity headers on MCP requests, we cannot implement per-user token isolation — all users share
a single OAuth token.

Being able to identify the user making MCP requests would enable:

  • Per-user OAuth token scoping in external tool gateways
  • Per-user audit logging for tool usage
  • Per-user rate limiting on tool calls
  • Multi-tenant MCP server deployments

Environment

  • MCP connection type: Streamable HTTP
  • ENABLE_FORWARD_USER_INFO_HEADERS=true is set
  • Headers confirmed working for LiteLLM (OpenAI-compatible) requests

Alternatives Considered

No response

Additional Context

No response

Originally created by @rpostulart on GitHub (Feb 3, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/21134 ### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description Description When ENABLE_FORWARD_USER_INFO_HEADERS=true is set, OpenWebUI correctly forwards X-OpenWebUI-User-Email, X-OpenWebUI-User-Id, X-OpenWebUI-User-Name, and X-OpenWebUI-User-Role headers to OpenAI-compatible API backends (e.g., LiteLLM). However, these headers are not forwarded to MCP Streamable HTTP tool server connections. Additionally, template variables like {{USER_EMAIL}} configured in MCP connection custom headers are sent as literal strings rather than being resolved to the actual user's email. Steps to Reproduce 1. Set ENABLE_FORWARD_USER_INFO_HEADERS=true on the OpenWebUI container 2. Configure an MCP Streamable HTTP tool server connection with custom headers: {"x-openwebui-user-id": "{{USER_EMAIL}}"} 3. Make a tool call from a chat 4. Inspect the headers received by the MCP server ### Desired Solution you'd like Expected Behavior Either: - Option A: ENABLE_FORWARD_USER_INFO_HEADERS should also forward X-OpenWebUI-User-Email (and other user info headers) to MCP Streamable HTTP connections, OR - Option B: Template variables like {{USER_EMAIL}} in MCP custom headers should be resolved to the actual user's email address Actual Behavior - No X-OpenWebUI-User-* headers are sent to MCP servers - {{USER_EMAIL}} in custom headers is sent as the literal string {{USER_EMAIL}} Headers received by the MCP server: x-openwebui-user-id: {{USER_EMAIL}} ← literal string, not resolved Missing headers (compared to LiteLLM requests): x-openwebui-user-email: (not present) x-openwebui-user-name: (not present) x-openwebui-user-role: (not present) Use Case We use AWS Bedrock AgentCore Gateway as an MCP server to provide Jira, Confluence, and Microsoft 365 tools. The gateway uses per-user OAuth tokens (3-legged OAuth) scoped by user identity. Without user identity headers on MCP requests, we cannot implement per-user token isolation — all users share a single OAuth token. Being able to identify the user making MCP requests would enable: - Per-user OAuth token scoping in external tool gateways - Per-user audit logging for tool usage - Per-user rate limiting on tool calls - Multi-tenant MCP server deployments Environment - MCP connection type: Streamable HTTP - ENABLE_FORWARD_USER_INFO_HEADERS=true is set - Headers confirmed working for LiteLLM (OpenAI-compatible) requests ### Alternatives Considered _No response_ ### Additional Context _No response_
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#19392
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?