MCP OAuth rejects a callback with no iss: what to do

A missing iss on the OAuth callback is rejected only when the client expects one. Gemini CLI rejects a callback without iss whenever an expected issuer is discovered or configured, and Codex rejects it when the server advertises issuer support. The MCP authorization spec rejects a missing iss only when the server's metadata says it sends one. If a login fails on this check, first update the client or check its issuer setting; an API-key header is the documented path only for automation that does not speak OAuth.

The rules below come from the MCP specification, Gemini CLI's MCP page and Codex's MCP page, all read 2026-09-29. The Sume facts come from MCP OAuth and API keys and, where marked, current code.

What is the iss parameter?

It is RFC 9207, OAuth 2.0 Authorization Server Issuer Identification. The authorization server adds iss=<issuer URL> to the redirect back to the client, so a client that talks to several servers can tell which one answered. It defends against mix-up attacks, where a code from one server is replayed to another.

The MCP spec says servers SHOULD include iss in authorization responses and, if they do, MUST set authorization_response_iss_parameter_supported to true in their metadata. It also says a future revision is expected to raise that from SHOULD to MUST.

Which clients reject a callback with no iss?

In the spec's table, a server that neither advertises the flag nor sends iss is the fourth row, and the client action there is to proceed. Codex's page says that when issuer support is not advertised it appends a server-specific callback ID to the callback, and that after a rejected response it neither exchanges the code nor falls back to another callback.

Does Sume send iss?

Not in current code. Sume's MCP authorization redirect carries only code and state, and its authorization-server metadata has an issuer field but not authorization_response_iss_parameter_supported. Under the spec's table that is the proceed row.

What this means for Gemini CLI depends on its own logic. Its page says a missing iss is rejected when an expected issuer is discovered or configured, and it does not say what discovery covers. This post does not claim it fails or works against Sume; check with a test login on your version.

What is the fallback if a client rejects the login?

Prefer fixing the client or its issuer setting. Sume's docs say the API-key path is for automation that does not speak OAuth, and they say not to mint API keys for hosted OAuth clients as a workaround, so an API key is a deliberate choice for a headless job, not a patch for a failed login. Sume's MCP accepts Authorization: Bearer <key> or x-api-key on https://mcp.sume.com/mcp, as described in MCP OAuth and API keys. An API-key session sees the full tool set, so keep the key in an environment variable, as in MCP config API key: use an environment variable.

The trade-off between the two paths is in MCP server API key vs OAuth.