fix: use discoverOAuthFromWWWAuthenticate for reactive OAuth flow (#18760)#19038
Conversation
handleAutomaticOAuth() was passing the resource_metadata URI (already a .well-known URL) to discoverOAuthConfig() which expects a server URL and constructs .well-known paths from it. This caused double-nested .well-known paths (404) and subsequent ResourceMismatchError for path-based MCP servers. Switch to discoverOAuthFromWWWAuthenticate() which directly fetches the resource_metadata URI and validates against the actual server URL, with fallback to base URL discovery. Fixes google-gemini#18760
Summary of ChangesHello @maximus12793, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request refines the OAuth authentication flow for MCP servers by addressing a critical issue where the discovery process could fail due to incorrect handling of Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
The pull request correctly addresses the issue of double-nested .well-known paths during OAuth discovery by utilizing the discoverOAuthFromWWWAuthenticate utility. This change ensures that when a resource_metadata URI is provided in the WWW-Authenticate header, it is fetched directly rather than being treated as a base URL for further path construction. The refactoring also improves code clarity by consolidating URL extraction logic and removing redundant variable declarations.
scidomino
left a comment
There was a problem hiding this comment.
Add a test and I will approve.
2eacf2d to
e72b076
Compare
|
@scidomino done, thanks! |
|
@maximus12793 we can't merge until you sign the CLA. Please do so. |
28f42f9 to
8226a9b
Compare
Fixed, sorry about that |
Summary
handleAutomaticOAuth()passing aresource_metadataURI (already a.well-knownURL) todiscoverOAuthConfig(), which expects a server URL — causing double-nested.well-knownpaths (404) andResourceMismatchErrorfor path-based MCP serversdiscoverOAuthFromWWWAuthenticate()utility which correctly fetches the resource metadata URI directly and validates against the actual server URLextractBaseUrl()in the fallback path instead of inline URL constructionRoot Cause
discoverOAuthConfig(resourceMetadataUri)constructs.well-knowndiscovery paths from its input. When the input is already a.well-knownURL parsed from theWWW-Authenticateheader, this produces double-nested paths that 404. The fallback then throwsResourceMismatchError.Fix
Use
discoverOAuthFromWWWAuthenticate()(already exists inoauth-utils.ts) which directly fetches theresource_metadataURI and validates against the actual server URL (RFC 9728 §7.3). Fallback to base URL discovery is preserved.Test plan
Fixes #18760
Supersedes #18798 (stalled on CLA)