auth: fetch AS metadata in well-known subpath from serverUrl even when PRM returns external AS #752
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When hitting a protected endpoint
https://foo.com/mcp
, we now query the integrated AS athttps://foo.com/.well-known/oauth-authorization-server/mcp
(w/ a fallback to justhttps://foo.com/.well-known/oauth-authorization-server
).BUT if there's an external AS defined in the PRM (e.g. if
https://foo.com/.well-known/oauth-protected-resource
returns{"authorization_servers":["https://some-auth.com"]...}
), we currently sidestep the subpath logic and only hithttps://some-auth.com/.well-known/oauth-authorization-server
.This change passes the auth server URL to
discoverOAuthMetadata
separately from the issuer URL (from which the subpath is to be fetched), and adds a test onauth
itself that fails before the change.Motivation and Context
How Has This Been Tested?
Breaking Changes
Types of changes
Checklist
Additional context