github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-07 11:28:35 -05:00
Code Issues 1.3k Packages Projects Releases 126 Wiki Activity

[GH-ISSUE #23867] MCP OAuth 2.1 (Static): HubSpot connection registers client but user authorization is not executed, request reaches MCP unauthenticated #58762

New Issue
Closed
opened 2026-05-05 23:52:10 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-05-05 23:52:10 -05:00
Owner
Copy Link

Originally created by @roller100 on GitHub (Apr 18, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23867

Summary

A remote MCP server configured in Open WebUI as OAuth 2.1 (Static) appears to register successfully, but the required per-user authorization flow is not resulting in an authenticated user session for the MCP request.

In our case this is HubSpot's official remote MCP server:

  • MCP URL: https://mcp.hubspot.com
  • Auth mode in UI: OAuth 2.1 (Static)
  • UI state: Registered

Expected behavior, based on the Notion MCP example and the product UX, is:

  1. the shared/static OAuth client is configured once by an admin
  2. each end user still has to authorize the app interactively
  3. Open WebUI then calls the remote MCP with that user's token

What actually happens is:

  • the static client info is built successfully
  • the request reaches https://mcp.hubspot.com
  • the remote MCP responds 401 Unauthorized
  • the user sees Failed to connect to MCP server 'HubSpot'

So the shared client registration succeeds, but the per-user authorization requirement is not being executed/applied to the live MCP request.

Environment

  • Open WebUI upstream base: v0.8.12
  • Deployment is built from upstream Open WebUI image with a minimal local overlay for the known oauth_session_id callback regression fix from commit 18f6ec68b9fdbb0ad702a45383a741d38ff922ee
  • The overlay was originally applied for a separate system_oauth production regression; current evidence suggests that fix is adjacent context, not the primary cause here

Reproduction

  1. Add a new MCP Streamable HTTP connection in Open WebUI
  2. URL: https://mcp.hubspot.com
  3. Choose OAuth 2.1 (Static)
  4. Register/save the client successfully
  5. Enable the HubSpot tool for a user chat session
  6. Attempt to use it

Expected Behavior

Each user should be required to authorize the HubSpot app interactively, similar to the Notion MCP pattern, and the resulting user token should be applied to the MCP request.

Actual Behavior

The request reaches the remote MCP unauthenticated and returns 401 Unauthorized.

What We Observed

From the Open WebUI logs:

2026-04-18 13:11:45.455 | INFO     | open_webui.utils.oauth:get_oauth_client_info_with_static_credentials:504 - Static OAuth client info built for HubSpot using metadata from https://mcp.hubspot.com/.well-known/oauth-authorization-server
2026-04-18 13:12:37.722 | INFO     | mcp.client.streamable_http:_maybe_extract_protocol_version_from_message:193 - Negotiated protocol version: 2025-11-25
2026-04-18 13:12:37.934 | INFO     | mcp.client.streamable_http:_maybe_extract_protocol_version_from_message:193 - Negotiated protocol version: 2025-11-25
2026-04-18 13:12:39.029 | INFO     | httpx._client:_send_single_request:1740 - HTTP Request: POST https://mcp.hubspot.com "HTTP/1.1 401 Unauthorized"
2026-04-18 13:12:54.561 | ERROR    | asyncio.runners:run:118 - Task exception was never retrieved
RuntimeError: Attempted to exit cancel scope in a different task than it was entered in

The 401 is the primary failure. The async cleanup exception appears secondary.

Additional Runtime Observations

From the stored Open WebUI connection state:

  • HubSpot connection exists
  • encrypted static OAuth client info is present
  • the tool appears in the tool list
  • but the tool list does not show it as authenticated for the user session

That combination suggests that the static client is registered, but the per-user token is either:

  • never being obtained
  • never being attached to the MCP request
  • or not being associated with the saved connection shape used by OAuth 2.1 (Static)

Why This Matters

For remote MCP providers like HubSpot, the whole point of the static-client mode is:

  • admin configures one client once
  • each user still authenticates as themselves

Right now the admin registration side appears to work, but the user authorization side does not.

Related Context

  • Discussion: #21195
  • This is not a generic HubSpot connectivity problem; the remote MCP is reachable and responds, but responds as unauthenticated
  • The main question is whether OAuth 2.1 (Static) is fully wired through the MCP runtime path for per-user authorization/token application

Request

Please verify whether OAuth 2.1 (Static) for remote MCP servers is expected to support per-user authorization end to end today.

If yes, this looks like a bug in the runtime path because the remote MCP call is going out without a user bearer token.

If no, the docs/UX need to say that much more explicitly, because the current flow strongly suggests that static client registration should still lead to per-user auth.

Originally created by @roller100 on GitHub (Apr 18, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/23867 ## Summary A remote MCP server configured in Open WebUI as `OAuth 2.1 (Static)` appears to register successfully, but the required per-user authorization flow is not resulting in an authenticated user session for the MCP request. In our case this is HubSpot's official remote MCP server: - MCP URL: `https://mcp.hubspot.com` - Auth mode in UI: `OAuth 2.1 (Static)` - UI state: `Registered` Expected behavior, based on the Notion MCP example and the product UX, is: 1. the shared/static OAuth client is configured once by an admin 2. each end user still has to authorize the app interactively 3. Open WebUI then calls the remote MCP with that user's token What actually happens is: - the static client info is built successfully - the request reaches `https://mcp.hubspot.com` - the remote MCP responds `401 Unauthorized` - the user sees `Failed to connect to MCP server 'HubSpot'` So the shared client registration succeeds, but the per-user authorization requirement is not being executed/applied to the live MCP request. ## Environment - Open WebUI upstream base: `v0.8.12` - Deployment is built from upstream Open WebUI image with a minimal local overlay for the known `oauth_session_id` callback regression fix from commit `18f6ec68b9fdbb0ad702a45383a741d38ff922ee` - The overlay was originally applied for a separate `system_oauth` production regression; current evidence suggests that fix is adjacent context, not the primary cause here ## Reproduction 1. Add a new MCP Streamable HTTP connection in Open WebUI 2. URL: `https://mcp.hubspot.com` 3. Choose `OAuth 2.1 (Static)` 4. Register/save the client successfully 5. Enable the HubSpot tool for a user chat session 6. Attempt to use it ## Expected Behavior Each user should be required to authorize the HubSpot app interactively, similar to the Notion MCP pattern, and the resulting user token should be applied to the MCP request. ## Actual Behavior The request reaches the remote MCP unauthenticated and returns `401 Unauthorized`. ## What We Observed From the Open WebUI logs: ```text 2026-04-18 13:11:45.455 | INFO | open_webui.utils.oauth:get_oauth_client_info_with_static_credentials:504 - Static OAuth client info built for HubSpot using metadata from https://mcp.hubspot.com/.well-known/oauth-authorization-server 2026-04-18 13:12:37.722 | INFO | mcp.client.streamable_http:_maybe_extract_protocol_version_from_message:193 - Negotiated protocol version: 2025-11-25 2026-04-18 13:12:37.934 | INFO | mcp.client.streamable_http:_maybe_extract_protocol_version_from_message:193 - Negotiated protocol version: 2025-11-25 2026-04-18 13:12:39.029 | INFO | httpx._client:_send_single_request:1740 - HTTP Request: POST https://mcp.hubspot.com "HTTP/1.1 401 Unauthorized" 2026-04-18 13:12:54.561 | ERROR | asyncio.runners:run:118 - Task exception was never retrieved RuntimeError: Attempted to exit cancel scope in a different task than it was entered in ``` The `401` is the primary failure. The async cleanup exception appears secondary. ## Additional Runtime Observations From the stored Open WebUI connection state: - HubSpot connection exists - encrypted static OAuth client info is present - the tool appears in the tool list - but the tool list does not show it as authenticated for the user session That combination suggests that the static client is registered, but the per-user token is either: - never being obtained - never being attached to the MCP request - or not being associated with the saved connection shape used by `OAuth 2.1 (Static)` ## Why This Matters For remote MCP providers like HubSpot, the whole point of the static-client mode is: - admin configures one client once - each user still authenticates as themselves Right now the admin registration side appears to work, but the user authorization side does not. ## Related Context - Discussion: `#21195` - This is not a generic HubSpot connectivity problem; the remote MCP is reachable and responds, but responds as unauthenticated - The main question is whether `OAuth 2.1 (Static)` is fully wired through the MCP runtime path for per-user authorization/token application ## Request Please verify whether `OAuth 2.1 (Static)` for remote MCP servers is expected to support per-user authorization end to end today. If yes, this looks like a bug in the runtime path because the remote MCP call is going out without a user bearer token. If no, the docs/UX need to say that much more explicitly, because the current flow strongly suggests that static client registration should still lead to per-user auth.
GiteaMirror commented 2026-05-05 23:52:12 -05:00
Author
Owner
Copy Link

@pr-validator-bot commented on GitHub (Apr 18, 2026):

⚠️ Missing Issue Title Prefix

@roller100, your issue title is missing a prefix (e.g., bug:, feat:, docs:).

Please update your issue title to include one of the following prefixes:

  • bug: Bug report or error you've encountered
  • feat: Feature request or enhancement suggestion
  • docs: Documentation issue or improvement request
  • question: Question about usage or functionality
  • help: Request for help or support

Example: bug: Login fails when using special characters in password

<!-- gh-comment-id:4273785687 --> @pr-validator-bot commented on GitHub (Apr 18, 2026): # ⚠️ Missing Issue Title Prefix @roller100, your issue title is missing a prefix (e.g., `bug:`, `feat:`, `docs:`). Please update your issue title to include one of the following prefixes: - **bug**: Bug report or error you've encountered - **feat**: Feature request or enhancement suggestion - **docs**: Documentation issue or improvement request - **question**: Question about usage or functionality - **help**: Request for help or support Example: `bug: Login fails when using special characters in password`
GiteaMirror commented 2026-05-05 23:52:12 -05:00
Author
Owner
Copy Link

@roller100 commented on GitHub (Apr 18, 2026):

Sorry, raised here in error, we are still investigating.

<!-- gh-comment-id:4273788769 --> @roller100 commented on GitHub (Apr 18, 2026): Sorry, raised here in error, we are still investigating.
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#58762
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?