[PR #24689] [CLOSED] fix(oauth): use Protected Resource Metadata scopes in static OAuth 2.1 flow #98820

New Issue

GiteaMirror · 2026-05-16T01:41:16-05:00

GiteaMirror commented

2026-05-16 01:41:16 -05:00

📋 Pull Request Information

Original PR: https://github.com/open-webui/open-webui/pull/24689
Author: @JustinJohnWilliams
Created: 5/13/2026
Status: ❌ Closed

Base: dev ← Head: fix/static-oauth-scopes-from-prm

📝 Commits (1)

b46d333 fix(oauth): use Protected Resource Metadata scopes in static OAuth 2.1 flow

📊 Changes

1 file changed (+14 additions, -8 deletions)

View changed files

📝 backend/open_webui/utils/oauth.py (+14 -8)

📄 Description

Summary

The static credentials OAuth 2.1 flow (oauth_2.1_static) currently sets scope=None, relying on the OAuth provider's default scopes. This breaks providers like GitHub that default to minimal/public-only access when no scope is requested — making it impossible to access private resources via MCP tool servers using static OAuth credentials.

This PR reads scopes_supported from the Protected Resource Metadata document (RFC 9728) and uses them in the authorization request.

Why this doesn't break Entra ID

The original change (349ea4ea) correctly identified that requesting all scopes from the Authorization Server Metadata breaks providers like Entra ID. However, the Protected Resource Metadata's scopes_supported is semantically different:

AS Metadata scopes_supported: Full catalog of every scope the authorization server can grant across all resources
PRM scopes_supported (RFC 9728 §2): Scopes required by this specific protected resource

Per the MCP spec's Scope Selection Strategy, clients should use scopes_supported from the Protected Resource Metadata when no explicit scope is provided in the WWW-Authenticate challenge.

Changes

Added scopes_supported field to ProtectedResourceMetadata dataclass
Extract scopes_supported from the PRM document during discovery (it was already being fetched but the field was discarded)
Use PRM scopes in the static credentials flow instead of None

Test plan

Verified GitHub MCP server's /.well-known/oauth-protected-resource returns appropriate scopes_supported (repo, read:org, etc.)
With this patch, OAuth authorization request includes scope=repo read:org ... and GitHub grants access to private org repos
Entra ID static OAuth flows continue to work (PRM document from Entra-backed MCP servers typically doesn't include scopes_supported, so behavior falls back to scope=None)

#23668 — the original issue that led to removing scope handling
#23696 — prior PR attempting to add admin-configurable scopes (closed due to CLA/branch)

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/open-webui/open-webui/pull/24689 **Author:** [@JustinJohnWilliams](https://github.com/JustinJohnWilliams) **Created:** 5/13/2026 **Status:** ❌ Closed **Base:** `dev` ← **Head:** `fix/static-oauth-scopes-from-prm` --- ### 📝 Commits (1) - [`b46d333`](https://github.com/open-webui/open-webui/commit/b46d333f25bcff236774122373458a2ba04b98ef) fix(oauth): use Protected Resource Metadata scopes in static OAuth 2.1 flow ### 📊 Changes **1 file changed** (+14 additions, -8 deletions) <details> <summary>View changed files</summary> 📝 `backend/open_webui/utils/oauth.py` (+14 -8) </details> ### 📄 Description ## Summary The static credentials OAuth 2.1 flow (`oauth_2.1_static`) currently sets `scope=None`, relying on the OAuth provider's default scopes. This breaks providers like GitHub that default to minimal/public-only access when no scope is requested — making it impossible to access private resources via MCP tool servers using static OAuth credentials. This PR reads `scopes_supported` from the **Protected Resource Metadata** document (RFC 9728) and uses them in the authorization request. ## Why this doesn't break Entra ID The original change (349ea4ea) correctly identified that requesting all scopes from the **Authorization Server Metadata** breaks providers like Entra ID. However, the Protected Resource Metadata's `scopes_supported` is semantically different: - **AS Metadata `scopes_supported`**: Full catalog of every scope the authorization server can grant across all resources - **PRM `scopes_supported`** (RFC 9728 §2): Scopes required by *this specific protected resource* Per the MCP spec's [Scope Selection Strategy](https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization), clients should use `scopes_supported` from the Protected Resource Metadata when no explicit scope is provided in the `WWW-Authenticate` challenge. ## Changes 1. Added `scopes_supported` field to `ProtectedResourceMetadata` dataclass 2. Extract `scopes_supported` from the PRM document during discovery (it was already being fetched but the field was discarded) 3. Use PRM scopes in the static credentials flow instead of `None` ## Test plan - [x] Verified GitHub MCP server's `/.well-known/oauth-protected-resource` returns appropriate `scopes_supported` (`repo`, `read:org`, etc.) - [ ] With this patch, OAuth authorization request includes `scope=repo read:org ...` and GitHub grants access to private org repos - [ ] Entra ID static OAuth flows continue to work (PRM document from Entra-backed MCP servers typically doesn't include `scopes_supported`, so behavior falls back to `scope=None`) ## Related issues - #23668 — the original issue that led to removing scope handling - #23696 — prior PR attempting to add admin-configurable scopes (closed due to CLA/branch) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

GiteaMirror added the pull-request label 2026-05-16 01:41:16 -05:00

GiteaMirror closed this issue

2026-05-16 01:41:22 -05:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#98820