Explicitly define the Authorization Base URL #165
Merged
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.
This PR defines how to construct the OAuth server's base URL from the SSE endpoint URL. This base URL is used to locate both the Metadata Discovery endpoint and Fallback authorization endpoints.
Motivation and Context
The draft Authorization Specification includes mention of a
baseUrlthat the Metadata and Fallback endpoints are constructed relative to. However, it doesn't specify how to actually construct thisbaseUrl.In the original Authorization Support PR there was some discussion about having a stricter definition for the server's
baseUrlalthough at the time it was unspecified.Given the implementations of OAuth Metadata Discovery in the Inspector and Typescript SDK it seems the
baseUrlis derived from simply taking the scheme, protocol, and port from the SSE Url used during connection.It's necessary for MCP Clients to understand how to construct this URL in order to properly authenticate, so this PR formalizes the definition relative to the SSE Url.
Another tiny problem was that there were multiple 2.3.1 sections in the Authorization page.
How Has This Been Tested?
Verified by running the docs locally that all links and references are correct and that everything looks fine visually.
Breaking Changes
None
Types of changes
Checklist
Additional context
The downside of this approach is the inflexibility it provides when wanting to host multiple MCP Servers on one domain. Down the line we'll likely want to allow the MCP Client to explicitly configure the Base/Issuer URL which would take priority. Also it's weird from the perspective of URL structure inconsistency, version management, etc.
Other options include: