-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Support falling back to OIDC metadata for auth #1061
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support falling back to OIDC metadata for auth #1061
Conversation
Thank you! Sorry, we had back and forth with this spec changes. For now it's on hold until modelcontextprotocol/modelcontextprotocol#797 is merged |
a956401
to
095c110
Compare
…-sdk into feat/oidc-fallback
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll add a claude generated review in addition, since I reviewed it and found it quite useful.
Here is Claude's take, which in this instance, I found helpful: Thank you for implementing RFC 9728 support with OIDC fallback functionality. While the implementation works, I have concerns about the complexity of the approach, particularly around the callback-based discovery stack pattern. Main Concerns1. Over-engineered Discovery Stack PatternThe current implementation uses a callback-based stack with function references: OAuthDiscoveryStack = list[Callable[[], Awaitable[httpx.Request]]] This pattern, combined with stack reversal and while-loop popping, adds unnecessary complexity:
2. Scattered URL Building LogicThe implementation has four separate methods for URL construction:
This fragmentation makes it harder to understand the discovery order and URL patterns. 3. Unnecessary State ManagementThe code stores intermediate state as instance variables: self.context.discovery_base_url = base_url
self.context.discovery_pathname = parsed.path These are only used for fallback logic and could be handled more cleanly. Suggested SimplificationReplace the callback stack with a straightforward URL list approach: def _get_discovery_urls(self) -> list[tuple[str, str]]:
"""Generate ordered list of (url, type) tuples for discovery attempts."""
urls = []
auth_server_url = self.context.auth_server_url or self.context.server_url
parsed = urlparse(auth_server_url)
base_url = f"{parsed.scheme}://{parsed.netloc}"
# RFC 8414: Path-aware OAuth discovery
if parsed.path and parsed.path != "/":
oauth_path = f"/.well-known/oauth-authorization-server{parsed.path.rstrip('/')}"
urls.append((urljoin(base_url, oauth_path), "oauth"))
# OAuth root fallback
urls.append((urljoin(base_url, "/.well-known/oauth-authorization-server"), "oauth"))
# RFC 8414 section 5: Path-aware OIDC discovery
if parsed.path and parsed.path != "/":
oidc_path = f"/.well-known/openid-configuration{parsed.path.rstrip('/')}"
urls.append((urljoin(base_url, oidc_path), "oidc"))
# OIDC 1.0 fallback (appends to full URL per spec)
oidc_fallback = urljoin(auth_server_url.rstrip("/"), "/.well-known/openid-configuration")
urls.append((oidc_fallback, "oidc"))
return urls Then in # Step 2: Discover OAuth metadata (with fallback for legacy servers)
discovery_urls = self._get_discovery_urls()
for url, discovery_type in discovery_urls:
request = httpx.Request("GET", url, headers={MCP_PROTOCOL_VERSION: LATEST_PROTOCOL_VERSION})
response = yield request
if response.status_code == 200:
try:
content = await response.aread()
metadata = OAuthMetadata.model_validate_json(content)
self.context.oauth_metadata = metadata
# Apply default scope if needed
if self.context.client_metadata.scope is None and metadata.scopes_supported is not None:
self.context.client_metadata.scope = " ".join(metadata.scopes_supported)
break
except ValidationError:
continue
elif response.status_code != 404:
break # Non-404 error, stop trying Benefits of This Approach
Minor Issues
OverallThe implementation is functionally correct and follows the RFCs properly. My suggestions are about reducing complexity and making the code more Pythonic. The callback pattern might make sense in other contexts, but here it adds unnecessary abstraction for what is essentially "try these URLs in order until one works." Would you consider simplifying the approach? Happy to discuss further or help with the refactoring. |
@ihrpr how do you want to sequence this? My suggestion is waiting for this PR to be in an acceptable state, then merge the spec change and the python sdk pr at the same time. |
Will make the changes by EOD tomorrow (juggling other things as well) - I agree with what you called out in general. For context, the reason I did it like this originally was because the entire OAuth flow was duplicated in the |
yes, that works, adding tracking for this as well |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Implements basic OIDC support for working with authorization servers that don't expose OAuth metadata, following the semantics described in RFC 8414 Section 5.
As part of this change, I modified the internal fallback behavior from a simple boolean flag to instead represent discovery as a stack of methods, which are consumed sequentially until one fallback method succeeds. This also helps clean up the duplicated code from working with
AsyncGenerator
.Motivation and Context
Enables falling back to OIDC 1.0 metadata when a server does not support OAuth metadata according to RFC 8414.
How Has This Been Tested?
Added/updated unit tests.
Breaking Changes
None
Types of changes
Checklist
Additional context
#976