Repository navigation
Select the advertised authorization server by the stored issuer - #680
Merged
koic merged 1 commit intoNov 13, 2026
Conversation
## Motivation and Context Protected resource metadata may list several authorization servers, and the flow always took the first. With `issuer:` on `ClientCredentialsProvider` and `CrossAppAccessProvider` that could not work: a resource listing the configured server second was refused as a different authorization server, although its metadata named the right one. A registered client fared the same: its stored client information records the server that issued the registration, and it was registered again at the first entry instead. The flow now prefers the entry naming the issuer recorded in the provider's client information, with the single trailing slash tolerance the issuer checks apply, and falls back to the first entry when nothing is recorded or listed; the checks that follow still decide, so a configured issuer the resource does not list is refused as before. The Python SDK's client credentials provider selects the advertised server the same way for its configured issuer. ## How Has This Been Tested? test/mcp/client/oauth/flow_test.rb: a resource listing the configured issuer second runs both machine-to-machine grants and the refresh at that server, a trailing slash difference still matches, an issuer the resource does not list is refused, a provider without an issuer keeps the first entry, and a registered client keeps its authorization server; before the change the tests that expect the second entry fail by picking the first. ## Breaking Changes None.
atesgoral
approved these changes
Nov 12, 2026
koic
deleted the
select_the_advertised_authorization_server_by_the_stored_issuer
branch
November 13, 2026 03:24
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Motivation and Context
Protected resource metadata may list several authorization servers, and the flow always took the first. With
issuer:onClientCredentialsProviderandCrossAppAccessProviderthat could not work: a resource listing the configured server second was refused as a different authorization server, although its metadata named the right one. A registered client fared the same: its stored client information records the server that issued the registration, and it was registered again at the first entry instead.The flow now prefers the entry naming the issuer recorded in the provider's client information, with the single trailing slash tolerance the issuer checks apply, and falls back to the first entry when nothing is recorded or listed; the checks that follow still decide, so a configured issuer the resource does not list is refused as before. The Python SDK's client credentials provider selects the advertised server the same way for its configured issuer.
How Has This Been Tested?
test/mcp/client/oauth/flow_test.rb: a resource listing the configured issuer second runs both machine-to-machine grants and the refresh at that server, a trailing slash difference still matches, an issuer the resource does not list is refused, a provider without an issuer keeps the first entry, and a registered client keeps its authorization server; before the change the tests that expect the second entry fail by picking the first.
Breaking Changes
None.
Types of changes
Checklist