MCP OAuth: Dataverse MCP rejected by RFC 8414 issuer check ( login.windows.net  vs  login.microsoftonline.com ), with and without a static  oauthClientId #5082

Describe the bug

Authenticating to a Dataverse (Dynamics 365) MCP server fails with:

MCPOAuthError: Incompatible authorization server: authorization server advertised an issuer that does not match the URL its metadata was discovered from (RFC 8414 §3.3); refusing to connect

The server's protected-resource metadata advertises  login.windows.net  as the authorization server. Microsoft's metadata at that address returns a different issuer,  login.microsoftonline.com . The strict issuer check rejects this, so sign-in never starts. It reproduces with and without a static  oauthClientId .

Logs from 1.0.88 and 1.0.90 show no such error. It first appears on 1.0.91 and persists through 1.0.94-3. I haven't confirmed that the connection succeeded on the earlier versions.

Affected version

1.0.94-3 (also seen on 1.0.91, 1.0.92, 1.0.93-4)

Steps to reproduce the behavior

1. Add a Dataverse MCP server to  ~/.copilot/mcp-config.json , with either configuration:

A. Static public client:

"dataverse-mcp": {
  "type": "http",
  "url": "https://<org>.<region>.dynamics.com/api/mcp",
  "tools": ["*"],
  "headers": {},
  "oauthClientId": "<app-registration-client-id>",
  "oauthPublicClient": true
}

B. Plain HTTP, no client ID:

"dataverse-mcp": {
  "type": "http",
  "url": "https://<org>.<region>.dynamics.com/api/mcp",
  "tools": ["*"],
  "headers": {}
}

2. Start a session and run  /mcp auth dataverse-mcp .
3. Authentication fails with the  Incompatible authorization server  error above. Both A and B fail identically, so the check fails during authorization-server discovery, before client registration.

Expected behavior

The CLI should be able to authenticate to this Microsoft-hosted endpoint. Options:

• Treat the known Entra hostname aliases ( login.windows.net ,  login.microsoftonline.com ,  sts.windows.net ) as equivalent for issuer comparison.
• Add a per-server opt-out such as  skipIssuerValidation , as requested in #4584, instead of a global setting.

Additional context

 GET https://<org>.<region>.dynamics.com/.well-known/oauth-protected-resource  returns:

{
  "resource_name": "Dataverse MCP Server",
  "resource": "https://<org>.<region>.dynamics.com/api/mcp",
  "authorization_servers": ["https://login.windows.net/<tenant-id>/v2.0"],
  "scopes_supported": ["openid","profile","offline_access","https://<org>.<region>.dynamics.com/api/mcp/mcp.tools"],
  "code_challenge_methods_supported": ["S256"]
}

 GET https://login.windows.net/<tenant-id>/v2.0/.well-known/openid-configuration  returns  "issuer": "https://login.microsoftonline.com/<tenant-id>/v2.0" .

 login.windows.net  is listed as an alias of  login.microsoftonline.com  by Microsoft's public instance discovery endpoint ( https://login.microsoftonline.com/common/discovery/instance?api-version=1.1&authorization_endpoint=https://login.microsoftonline.com/common/oauth2/v2.0/authorize ,  aliases  list for the public cloud).

A bearer token from  az account get-access-token  is rejected by the endpoint (HTTP 403, only registered client apps are allowed), so a manual  Authorization  header isn't a workaround.