MCP server settings should allow specifying an external OAuth identity provider

[draeron]

Body

Description

When an MCP server delegates OAuth to an external IdP (e.g. Microsoft Entra/Azure AD), Zed fails during discovery with:

OAuth discovery failed: Auth server metadata issuer mismatch: expected https://<mcp-server>/, got https://login.microsoftonline.com/<tenant-id>/v2.0

The MCP server hosts /.well-known/oauth-authorization-server with an issuer pointing to the real token issuer (Entra). This is a standard enterprise delegation pattern — the issuer cannot simply be changed to the MCP server's own URL without breaking JWT token validation.

Feature Request

It should be possible to configure the OAuth issuer URL directly in the MCP server settings, for example:

{
  "context_servers": {
    "my-server": {
      "url": "https://my-mcp-server.com",
      "oauth_issuer": "https://login.microsoftonline.com/<tenant-id>/v2.0"
    }
  }
}

This would allow Zed to skip the issuer mismatch check and proceed with the OAuth flow using the correct external IdP, which is a common requirement in enterprise environments.

Environment

• Zed version: 0.230.1
• OS: macOS tahoe

[nertzy]

The Slack MCP server triggers this as well:

    "Slack": {
      "url": "https://mcp.slack.com/mcp",
    },

[cf-rdegregory]

The Atlassian MCP server has the same problem.

[acartag7]

@draeron , a server-side option for your case, since this flag may be a long wait: the oauth_issuer override would actually fix the wrong layer. Even if Zed skipped the issuer-mismatch check, the flow would next die on Entra's missing Dynamic Client Registration (Entra has no registration endpoint), so the override alone can't get you to a token.

What works today with unmodified Zed: give the MCP server its own small authorization server (a bridge) instead of pointing the metadata at Entra. The bridge is the issuer, so Zed's issuer validation passes as-is, and it accepts dynamic client registration from any MCP client, while Entra stays the identity source behind it as one ordinary pre-registered app. It mints its own short-lived tokens for the MCP session; Entra tokens never reach the client, and your JWT validation concern disappears because the tokens Zed sees are the bridge's, not Entra's.

Disclosure: I maintain an MIT Node library implementing this, mcp-sso, with an Entra identity port. Runs as a library or as a standalone gateway in front of a non-Node backend. Happy to help if you try it, issues get fixed fast.

To be fair to the rest of the thread: @nertzy's and @cf-rdegregory's cases (Slack, Atlassian) are vendor-hosted servers, so a bridge can't help there, those genuinely need the client-side fix this discussion asks for, it could if you use an api key mcp connection behind something like mcp-sso.