Skip to content

Comments

Add 2025-03-26 OAuth backward compatibility for client conformance#1374

Open
jeffhandley wants to merge 4 commits intomodelcontextprotocol:mainfrom
jeffhandley:jeffhandley/backcompat
Open

Add 2025-03-26 OAuth backward compatibility for client conformance#1374
jeffhandley wants to merge 4 commits intomodelcontextprotocol:mainfrom
jeffhandley:jeffhandley/backcompat

Conversation

@jeffhandley
Copy link
Collaborator

Implement legacy OAuth fallback so the client can authenticate against MCP servers that predate Protected Resource Metadata (RFC 9728):

  • When PRM discovery fails, synthesize minimal metadata using the MCP server's origin as the authorization server
  • When auth server metadata discovery also fails, fall back to the default endpoint paths (/authorize, /token, /register) specified by the MCP 2025-03-26 spec
  • Conditionally omit the 'resource' parameter from authorization and token requests when operating in legacy mode
  • Skip resource-match verification only for synthesized (not fetched) PRM

Enable the two previously-commented-out client conformance test scenarios:
auth/2025-03-26-oauth-metadata-backcompat
auth/2025-03-26-oauth-endpoint-fallback

Implement legacy OAuth fallback so the client can authenticate against
MCP servers that predate Protected Resource Metadata (RFC 9728):

- When PRM discovery fails, synthesize minimal metadata using the MCP
  server's origin as the authorization server
- When auth server metadata discovery also fails, fall back to the
  default endpoint paths (/authorize, /token, /register) specified by
  the MCP 2025-03-26 spec
- Conditionally omit the 'resource' parameter from authorization and
  token requests when operating in legacy mode
- Skip resource-match verification only for synthesized (not fetched) PRM

Enable the two previously-commented-out client conformance test scenarios:
  auth/2025-03-26-oauth-metadata-backcompat
  auth/2025-03-26-oauth-endpoint-fallback

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@jeffhandley jeffhandley added this to the 1.0.0 (GA) milestone Feb 24, 2026
@jeffhandley jeffhandley self-assigned this Feb 24, 2026
Copy link
Contributor

@halter73 halter73 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@FICTURE7 With these changes, we might be able to close #1262 considering the client should just work with the legacy auth used by the Atlassian server.

jeffhandley and others added 2 commits February 23, 2026 23:52
Refactor GetAuthServerMetadataAsync to accept an allowDefaultFallback
parameter and return BuildDefaultAuthServerMetadata directly instead of
throwing and catching McpException at the call site.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add two tests to AuthTests.cs covering legacy server scenarios:

- CanAuthenticate_WithLegacyServerWithoutProtectedResourceMetadata:
  Server lacks RFC 9728 PRM but serves auth server metadata at
  well-known URLs on the MCP server origin.

- CanAuthenticate_WithLegacyServerUsingDefaultEndpointFallback:
  Server lacks both PRM and auth server metadata, forcing fallback
  to default /authorize, /token, /register endpoint paths.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@jeffhandley jeffhandley requested a review from halter73 February 24, 2026 08:13
Comment on lines +1084 to +1087
"issuer": "{{OAuthServerUrl}}",
"authorization_endpoint": "{{OAuthServerUrl}}/authorize",
"token_endpoint": "{{OAuthServerUrl}}/token",
"registration_endpoint": "{{OAuthServerUrl}}/register",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should be using McpServerUrl rather than OAuthServerUrl for the above to really replicate the legacy scenario. It looks like we're proxying these endpoints using CanAuthenticate_WithLegacyServerUsingDefaultEndpointFallback. I think we should do the same here, and that should be possible.

In reality, this would fail due to a resource mismatch if the OAuth server validated it (we don't because TestOAuthServer.RequireResource = false is set in this test). I think it's better to test the fallback scenario where we skip using the resource. Maybe we should only update the RequireResource` logic in test server to only pass if the resource is missing rather than invalid.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants