OAuth scope selection falls back to the authorization server's scopes_supported, which the spec does not allow

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#3,781 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
79/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
python
Domaine
authentication

Piste de recherche

Commencez dans src/mcp/client/auth/utils.py, à get_client_metadata_scopes, et suivez les branches de sélection des scopes en les comparant au comportement de la spécification cité dans l’issue. Vérifiez ou ajoutez des tests ciblés pour un scope de challenge manquant et pour PRM scopes_supported ; le travail est terminé lorsque ces cas sélectionnent les scopes PRM s’ils sont présents et omettent le scope dans le cas contraire, sans utiliser les scopes du serveur d’autorisation.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug v1 v2
Initial Checks
Description

When the 401 carries no scope and the Protected Resource Metadata (PRM) has no scopes_supported, get_client_metadata_scopes (src/mcp/client/auth/utils.py) requests every scope the authorization server lists:

# MCP spec scope selection priority:
#   1. WWW-Authenticate header scope
#   2. PRM scopes_supported
#   3. AS scopes_supported (SDK fallback)
#   4. Omit scope parameter
...
elif authorization_server_metadata is not None and authorization_server_metadata.scopes_supported is not None:
    selected_scope = " ".join(authorization_server_metadata.scopes_supported)

The spec has two steps, and the second one ends in omitting scope (2026-07-28, Authorization → Scope Selection Strategy):

  1. Use scope parameter from the initial WWW-Authenticate header in the 401 response, if provided
  2. If scope is not available, use all scopes defined in scopes_supported from the Protected Resource Metadata document, omitting the scope parameter if scopes_supported is undefined.

The same section says clients SHOULD request "only the scopes necessary for their intended operations."

An authorization server's scopes_supported describes the whole authorization server, not this resource. Often that's a shared IdP serving many APIs (openid, profile, email, org-admin and write scopes for unrelated services). Tier 3 therefore turns "the resource didn't say" into "ask for everything the IdP has". The results:

  • an over-privileged token for an MCP server that needed none of it;
  • a broad consent screen for the user;
  • a login failure when the authorization server refuses to issue some of the listed scopes to a public or dynamically registered client (invalid_scope), where omitting scope would have succeeded with the authorization server's default.
Example Code

The selection function on its own (works on 1.26.0, 1.30.0 and 2.3.0):

from mcp.client.auth.utils import get_client_metadata_scopes
from mcp.shared.auth import OAuthMetadata, ProtectedResourceMetadata

prm = ProtectedResourceMetadata(
    resource="https://mcp.example.com/mcp",
    authorization_servers=["https://auth.example.com"],
)  # no scopes_supported
asm = OAuthMetadata(
    issuer="https://auth.example.com",
    authorization_endpoint="https://auth.example.com/authorize",
    token_endpoint="https://auth.example.com/token",
    scopes_supported=["openid", "profile", "email", "admin:org", "repo:write"],
)
print(get_client_metadata_scopes(None, prm, asm))
# 'openid profile email admin:org repo:write'   — expected: None (omit scope)

In the real flow, OAuthClientProvider.async_auth_flow assigns this result to client_metadata.scope on every 401. So a client can't avoid it by configuring a narrower scope: that is #2317, which has several production reports.

Expected behaviour

Follow the spec: (1) the challenge scope, (2) PRM scopes_supported, otherwise omit scope. If a fallback beyond the spec is wanted, make it something a client turns on, not the default.

Relation to existing issues
  • #2317: a configured client_metadata.scope is overwritten. This issue is separate: even with no configured scope, the SDK should omit scope rather than take the authorization server's list. Fixing #2317 alone would leave clients that don't configure a scope on tier 3.
  • #3172 (closed): put the configured scope after tier 3. That doesn't help here, because the AS-wide list still wins whenever the authorization server advertises any scopes.
Python & MCP Python SDK
  • MCP Python SDK: reproduced on 1.26.0, 1.30.0, 2.3.0. The same code is on main at d7845c0.
  • Python 3.12
Langage dominant
Python
Étoiles
24.7k
Forks
4.1k
Merge moyen
18 h 27 min
PR mergées (30 j)
15

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de modelcontextprotocol/python-sdk

Toutes les issues de modelcontextprotocol/python-sdk

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.