auth: validate unadvertised RFC 9207 iss instead of rejecting it - #1187
Open
asjdf wants to merge 2 commits into
Open
auth: validate unadvertised RFC 9207 iss instead of rejecting it#1187asjdf wants to merge 2 commits into
asjdf wants to merge 2 commits into
Conversation
When an authorization response includes iss, always compare it to the expected issuer (RFC 9207 §2.4) rather than failing solely because the server omitted authorization_response_iss_parameter_supported.
asjdf
marked this pull request as ready for review
August 20, 2026 08:48
asjdf
changed the title
Comment on lines
+619
to
+623
| // per [RFC 9207]. When iss is present it is always compared to expectedIssuer | ||
| // (RFC 9207 §2.4), even if the server did not advertise | ||
| // authorization_response_iss_parameter_supported. An unadvertised matching iss | ||
| // is accepted; a mismatch is rejected. Absence of iss is an error only when | ||
| // the server advertised support. |
Contributor
There was a problem hiding this comment.
According to spec
However, there might be legitimate authorization servers that provide the iss parameter without indicating their support in their metadata. Local policy or configuration can determine whether to accept such responses, and specific guidance is out of scope for this specification.
What do you think about adding a configurable value in AuthorizationCodeHandlerConfig to let the client define the local policy if accepting or not
Author
There was a problem hiding this comment.
Good call — added AcceptUnadvertisedIss on AuthorizationCodeHandlerConfig as the local policy knob.
- Zero value (
false) keeps the released v1.7.0 behavior: if metadata does not advertiseauthorization_response_iss_parameter_supportedandissis present, we reject. - Set
AcceptUnadvertisedIss: trueto accept a matching unadvertisediss(Sentry/Linear/Notion-style servers). - A wrong
issis still rejected either way; we never accept a mismatch.
Pushed on this branch in 7fdf782.
Keep the released default of rejecting an unadvertised matching iss, and let callers opt in for servers that send iss without advertising it.
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
2 participants
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.
Summary
Fixes #1152.
Sentry, Linear, and Notion omit
authorization_response_iss_parameter_supportedfrom their authorization-server metadata. Sentry still sends a correctissin the authorization response, so sign-in fails after the browser step: the user has already consented and an authorization code has been issued, butvalidateIssuerResponserejects the exchange solely because the server did not advertise RFC 9207 support.RFC 9207 §2.4 says clients MUST extract and compare
isswhen the parameter is present. §2.4 also notes that clients SHOULD discard an unadvertisediss, but that is a recommendation and local policy may accept servers that sendisswithout advertising. Validating a matchingissis interoperable with those hosted MCP servers and still catches mix-up attacks: a wrongissis rejected whether or not support was advertised.When
issis present, this change always compares it to the expected issuer (simple string equality). A match is accepted even if the server did not advertise support. A mismatch still returnsauthorization response issuer %q does not match expected issuer %q. Absence ofissremains an error only when the server advertised support.Test plan
go test ./auth/ -run TestValidateIssuerResponse -count=1go test ./auth/...New
TestValidateIssuerResponsecases:UnadvertisedIssCorrect:iss == expectedIssuer,issSupported == false→ no errorUnadvertisedIssWrong:iss == "https://attacker.example.com",issSupported == false→ error containingdoes not match expected issuerExisting advertised+match / advertised+mismatch / missing-iss cases are unchanged.