fix: include "none" in token_endpoint_auth_methods_supported metadata

[namabile]

Summary

build_metadata() in mcp/server/auth/routes.py hardcodes token_endpoint_auth_methods_supported to ["client_secret_post", "client_secret_basic"], omitting "none". This breaks public client OAuth flows used by MCP clients like Claude Code and Cursor.

Spec References

• MCP Authorization Spec (2025-06-18): "Authorization servers MUST implement OAuth 2.1 with appropriate security measures for both confidential and public clients." Best practices: "We strongly recommend that local clients implement OAuth 2.1 as a public client."
• RFC 7591 Section 2: token_endpoint_auth_method: "none" — "The client is a public client as defined in OAuth 2.0, Section 2.1, and does not have a client secret."
• RFC 8414 Section 2: token_endpoint_auth_methods_supported uses values from RFC 7591, which includes "none".
• Official MCP example server: Uses token_endpoint_auth_methods_supported: ['none'] — the Python SDK is the outlier.

The Problem

The registration handler (register.py:54-60) already supports public clients — it skips client_secret generation when token_endpoint_auth_method: "none". But the metadata doesn't advertise this capability, so clients assume a secret is always required and fail during token exchange.

Changes:

• Add "none" to token_endpoint_auth_methods_supported in build_metadata()
• Add "none" to revocation_endpoint_auth_methods_supported for consistency
• Update test assertions

Fixes #2260

Test plan

• uv run pytest tests/client/test_auth.py::test_build_metadata — 2 passed, 1 xfailed
• uv run pytest tests/server/fastmcp/auth/test_auth_integration.py — 40 passed
• uv run ruff check — all checks passed
• uv run ruff format --check — already formatted
• Manual verification: MCP server metadata now advertises "none", allowing Claude Code to complete public client OAuth flow

[maxisbey]

Thanks for the PR, and sorry it sat here without a proper review.

We're closing most of the open PR backlog. v2 is out and changed a lot of the SDK, so many older PRs no longer apply as written, and we're a small team that realistically doesn't have the capacity to work through the rest.

If this still matters to you on v2, the most useful thing you can do is open an issue (or comment on the existing one) with your use case and a repro. Hearing why it matters to you is what we use to decide what to prioritise.

_{AI Disclaimer}