Skip to content

auth/extauth: validate the RFC 9207 iss in PerformOIDCLogin - #1442

Merged
guglielmo-san merged 2 commits into
modelcontextprotocol:mainfrom
akshita317:extauth-oidc-login-check-iss
Oct 26, 2026
Merged

guglielmo-san merged 2 commits into
modelcontextprotocol:mainfrom
akshita317:extauth-oidc-login-check-iss

Conversation

@akshita317

Copy link
Copy Markdown
Contributor

AuthorizationCodeHandler validates the iss parameter of the authorization response (RFC 9207), the mitigation for mix-up attacks added in #859. extauth.PerformOIDCLogin, which obtains the ID token for Enterprise Managed Authorization, only compared the state: the Iss reported by the AuthorizationCodeFetcher was ignored. So a response naming another issuer, or one without iss from an IdP that advertises authorization_response_iss_parameter_supported, was accepted and its code exchanged at the IdP's token endpoint.

This checks iss right after the state, against the issuer and the flag from the IdP metadata that initiateOIDCLogin already fetches:

  • If the IdP advertises support, iss is required.
  • A present iss must equal the metadata issuer, whether or not support is advertised (RFC 9207 §2.4 asks clients to compare it).
  • A missing iss from an IdP that does not advertise support is accepted, as before.

Unlike AuthorizationCodeHandler, a matching but unadvertised iss is accepted (what AcceptUnadvertisedIss opts into there): PerformOIDCLogin never rejected it, so refusing it now would break IdPs that send iss without advertising it, and RFC 9207 §2.4 asks for validation rather than rejection (see #1152).

Tests:

  • internal/oauthtest: the fake IdP gets an IssParameterSupported option that advertises support and adds iss to its redirects.
  • TestPerformOIDCLogin_Issuer: advertised and not advertised, each with a missing, matching and foreign iss. The three rejected cases fail without the change; the existing TestPerformOIDCLogin cases are unchanged.

AI assistance: prepared with Claude Code.

AuthorizationCodeHandler validates the iss parameter of the
authorization response (RFC 9207), the mitigation for mix-up attacks,
but PerformOIDCLogin only compared the state. The iss reported by the
AuthorizationCodeFetcher was ignored, so a response naming another
issuer, or lacking iss from an IdP that advertises
authorization_response_iss_parameter_supported, was accepted and its
code exchanged at the IdP's token endpoint.

Check it after the state: iss is required when the IdP's metadata
advertises support, and a present iss must equal the issuer from that
metadata. A matching iss is accepted even when support is not
advertised, as RFC 9207, section 2.4, asks clients to compare it.

The fake IdP gets an IssParameterSupported option that advertises
support and adds iss to its redirects. TestPerformOIDCLogin_Issuer
covers both cases with a missing, matching and foreign iss; the three
rejected cases fail without the change.
@guglielmo-san
guglielmo-san merged commit fa799c5 into modelcontextprotocol:main Oct 26, 2026
15 of 17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants