Skip to content

fix(auth): oauth metadata discovery#641

Merged
alexhancock merged 2 commits intomodelcontextprotocol:mainfrom
glicht:fix/auth-meta-discovery
Feb 4, 2026
Merged

fix(auth): oauth metadata discovery#641
alexhancock merged 2 commits intomodelcontextprotocol:mainfrom
glicht:fix/auth-meta-discovery

Conversation

@glicht
Copy link
Contributor

@glicht glicht commented Feb 2, 2026

Auth metadata discovery stopped checking <base_domain>/.well-known/oauth-authorization-server with the 0.13 release. Adding a fix.

Motivation and Context

See #632

How Has This Been Tested?

Added unit test that failed before the fix and passes after the fix

Breaking Changes

No

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • [ x I have added or updated documentation as needed

Additional context

@wdawson
Copy link

wdawson commented Feb 2, 2026

This was due to an intentional correction in the MCP spec version 2025-11-25

@glicht
Copy link
Contributor Author

glicht commented Feb 3, 2026

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

@wdawson
Copy link

wdawson commented Feb 3, 2026

This was due to an intentional correction in the MCP spec version 2025-11-25

@wdawson see #632

The change that was implemented was a breaking change. I don't think that was the purpose. The sdk stopped working with common mcp servers (such as cloudflare).

Also from what I checked in the typescript-sdk it supports fetching from: <base_domain>/.well-known/oauth-authorization-server as a fallback. So, I think we should maintain this support for backwards compatibility.

@glicht I think it's ok. Just wanted to point out why it was done. I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

Copy link
Contributor

@tanish111 tanish111 left a comment

Choose a reason for hiding this comment

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

@glicht tested locally?

@tanish111
Copy link
Contributor

tanish111 commented Feb 4, 2026

@alexhancock can you also look into it issue and fix once?

@glicht
Copy link
Contributor Author

glicht commented Feb 4, 2026

@glicht tested locally?

Yes. I've tested locally and the fix works as expected. Thanks

@alexhancock
Copy link
Collaborator

@wdawson @tanish111 @glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

@alexhancock
Copy link
Collaborator

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

@github-actions github-actions bot added T-core Core library changes T-transport Transport layer changes labels Feb 4, 2026
@glicht
Copy link
Contributor Author

glicht commented Feb 4, 2026

@glicht for this one specifically, looks like it needs the code formatter run. cargo fmt should do it

Thanks. I've pushed a format fix.

@wdawson
Copy link

wdawson commented Feb 4, 2026

@wdawson @tanish111 @glicht re:

I think the bigger problem is that this SDK seems to not use the protected resource metadata location and tries to discover something first. Fixing that bug might fix this issue with Cloudflare

I feel like we've made a patchwork set of fixes/adjustments/tweaks over time. I get so confused by the ordering needed!

Is anyone well positioned to take a holistic look at how the Rust SDK gets/uses resource metadata?

@alexhancock I'm happy to take a pass. I know there are several issues and PRs in flight and I don't know the history. But I was a contributor to some of the authorization changes (hopefully the less confusing ones 😅) and should be able to get to a "correct" implementation if that would be a good starting point. Then would love help testing that against all the things people need/want to make sure there aren't regressions like @glicht mentioned. Let me know if that approach is useful. Alternatively I can review or advise another implementor. Happy to chat on discord or whatever.

@alexhancock alexhancock self-requested a review February 4, 2026 16:57
@alexhancock alexhancock merged commit f6ebc7a into modelcontextprotocol:main Feb 4, 2026
11 checks passed
@alexhancock
Copy link
Collaborator

Yes @wdawson let's do a comprehensive change that addresses all edge cases in this space and makes the implementation of metadata discovery & handling correct.

Then when we have a branch where we believe everything functions 100% to spec, I can make a test build of goose (the other project I work on) which uses the branch and we can test with various servers before a merge

Thanks for being willing to help!

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

Labels

T-core Core library changes T-transport Transport layer changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants