Protected Resource Metadata request failed: 404

[daltonnyx]

Initial Checks

• I confirm that I'm using the latest version of MCP Python SDK
• I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue

Description

In python-sdk v1.18.0, the PR #1324 introduced new scopes selection and step-up authorization. but in the step 1

python-sdk/src/mcp/client/auth.py

Lines 272 to 273 in 40acbc5

	else:
	raise OAuthFlowError(f"Protected Resource Metadata request failed: {response.status_code}")

It raise an error if the oauth-protected-resource url is not found on server. this cause issue for old mcp server that does not support it yet. for example https://mcp.linear.app/sse or https://mcp.atlassian.com/v1/sse

Since we still allows discover fallback url in step 4. I suggest we should remove this exception and let the flow fall through.

Example Code

Python & MCP Python SDK

python=3.12
mcp=v1.18.0

[dogacancolak]

Both the latest and the draft MCP specs say that:

MCP servers MUST implement OAuth 2.0 Protected Resource Metadata (RFC9728). MCP clients MUST use OAuth 2.0 Protected Resource Metadata for authorization server discovery.

However, I agree that we should minimize breaking changes. I checked if the lack of PRM would break anything in the later stages if we just let it fall through. Probably the most important things that PRM gives us is the Auth Server Metadata URL and which scopes to request.

Following the examples of the two MCP servers you provided, both Linear and Atlassian expose the Auth Server Metadata endpoint in one of the well-known fallback endpoints, so that part is good.

The scope selection strategy depends on the WWW-Auth response header, or the PRM endpoint as a fallback. Otherwise no scopes are requested. It seems that in Atlassian's /authorize endpoint, the user is able to manually select which scopes they want without the MCP client dynamically deciding them: https://support.atlassian.com/atlassian-rovo-mcp-server/docs/authentication-and-authorization/

It seems that both the Auth Server Metadata endpoint and scope exploration are safe, at least speaking for these MCP servers. I support your suggestion to let it fall through. I can raise a follow-up PR to remove the exception.

[dogacancolak]

@pcarleton Do you have an inclination between implementing the spec exactly vs opening up potentially undefined fall-back behavior to reduce breaking changes?