"Issuer mismatch in authorization_response" — RFC 9207 iss does not match the metadata issuer
The reference MCP client checks the iss parameter on the authorization response against the issuer it discovered (RFC 9207). When your identity provider signs in from one hostname and your protected-resource metadata names another, the callback is refused — after the user has already consented.
npx mcpcomp verify --interactive https://mcp.example.com/mcpRegisters dynamically, prints the authorization URL, captures the callback on loopback, and reports which stage failed — authorization (state, iss, code), token exchange, or the authenticated call.
What the error means
The message is "Issuer mismatch in authorization_response: expected <issuer>, received <iss>". expected is yours — it comes from the authorization-server metadata your PRM points at. received is whatever arrived on the redirect: normally your IdP, which is why a mismatch is worth refusing (RFC 9207 exists to stop mix-up attacks). A custom-domain tenant whose metadata still names the vendor host, or an issuer setting that differs from the PRM entry by path or host, can produce this. The same error fires when iss is absent after the metadata advertised authorization_response_iss_parameter_supported. Passive metadata can grade A while this fails, because the break is on the redirect leg.
How to diagnose it
Exercise the redirect leg, not just the metadata
mcpcomp verify --interactive drives the real authorization-code flow through the SDK's own auth() and finishAuth(), so the exact iss comparison the client makes is what fails or passes. The passive scan reports whether authorization_response_iss_parameter_supported is advertised at all.
Make the three issuers one string
The callback iss is compared to the metadata issuer by exact string equality; the PRM entry is tolerated to a trailing slash. Publish one form everywhere — scheme, host, path — fix the IdP's issuer setting or the PRM, then re-run verify.
Frequently asked questions
Why did this start happening without a deploy?
The identity provider's configuration moved — a custom domain enabled, an issuer setting changed. A committed baseline scan would have reported asMetadata.issuer changing on the day it happened.
Can I just disable the check?
Not in the reference client. RFC 9207 exists to stop mix-up attacks, and the 2026-07-28 spec requires the validation.