“Issuer mismatch”

The authorization server's metadata (or its authorization response) names a different issuer from the one the client looked up, and since the 2026-07-28 revision a client must not use metadata that does. The three common causes: (1) The metadata's `issuer` drops the path or uses another host than the URL in the protected-resource metadata's `authorization_servers`. To tell: The doctor fails at `issuer`, printing both values. (2) The protected-resource metadata lists the MCP server's own URL as the authorization server while the metadata it serves names another issuer. To tell: The doctor fails at `issuer`, and the advertised authorization server is the MCP URL itself. (3) A client bug: the expected issuer taken from the resource URL, or a trailing slash stripped before comparing. To tell: The doctor passes `issuer`; the issue numbers below match your client. One command shows which step breaks: npx --allow-git=root github:agentwares/mcp-oauth-doctor https://your-server.example/mcp --client claude-code.

Check your server now

npx --allow-git=root github:agentwares/mcp-oauth-doctor https://your-server.example/mcp --client claude-code

Discovery only: no credential, no client registration. It prints the first broken step, whose it is, and the fix with the spec section.

Who prints it

the MCP TypeScript SDK 2.x ("Issuer mismatch in authorization server metadata (RFC 8414 §3.3)"), Claude Code's 2026-07-28 runtime ("Issuer mismatch in authorization response (RFC 9207)") and Codex ("Authorization server issuer mismatch").

The three causes, and how to tell them apart

1. Cause 1. The metadata's `issuer` drops the path or uses another host than the URL in the protected-resource metadata's `authorization_servers`.
   The check fails at step as-issuer. The doctor fails at `issuer`, printing both values.
2. Cause 2. The protected-resource metadata lists the MCP server's own URL as the authorization server while the metadata it serves names another issuer.
   The check fails at step as-issuer. The doctor fails at `issuer`, and the advertised authorization server is the MCP URL itself.
3. Cause 3. A client bug: the expected issuer taken from the resource URL, or a trailing slash stripped before comparing.
   The check cannot see this one from outside: it happens after consent, or inside the client. The doctor passes `issuer`; the issue numbers below match your client.

Public reports

• atlassian/atlassian-mcp-server#205, opened 27 July 2026: authv2 issuer mismatch blocks strict clients; 35 reactions, reopened
• openai/codex#38944, opened 17 August 2026: Meta's server names its own URL as the authorization server; open
• openai/codex#40885, opened 26 August 2026: Codex takes the expected issuer from the resource URL; open
• openai/codex#37373, opened 7 August 2026: Codex 0.147 strips the trailing slash from the expected issuer; open

Keep checking

Re-check it every hour and email me when a step breaks: agentcheck's free watch, no account — it follows the sign-in a new client follows, with these same rules.

Nightly, with history: mcpcheck Server Pro re-runs these sign-in checks against the server every night, with 90 days of history, and emails when one fails ($49 a server a month; the first run is free).

Other messages

• “Authorization with the MCP server failed”
• “Couldn't reach the MCP server”
• “Failed to discover OAuth metadata”
• “Dynamic Client Registration not supported”
• “Incompatible auth server: does not support dynamic client registration”
• “invalid_redirect_uri”
• “Connection expired”
• “token exchange failed”

Written 8 October 2026 from the public issues above. The sign-in check · MCP Liveness · Terms · Privacy