Copilot CLI 1.0.92 rejects standard Entra api:// scopes for remote MCP servers

[teamstap100]

Describe the bug

Copilot CLI 1.0.92 rejects standard Entra api:// scopes for remote MCP servers

Describe the bug

GitHub Copilot CLI 1.0.92 rejects valid Microsoft Entra delegated scopes advertised by remote MCP servers when the scope uses the standard Entra api://<application-id>/<scope> Application ID URI format instead of the MCP server URL origin.

The rejection happens locally, before browser sign-in and before any request reaches the authorization server or MCP server.

For this MCP endpoint:

https://tap-mcp.core.microsoft/mcp

RFC 9728 protected-resource metadata is:

{
  "resource": "https://tap-mcp.core.microsoft/mcp",
  "authorization_servers": [
    "https://login.microsoftonline.com/72f988bf-86f1-41af-91ab-2d7cd011db47/v2.0"
  ],
  "scopes_supported": [
    "api://727d2113-3d8f-4203-9185-4a67a67a743b/mcp.access"
  ],
  "bearer_methods_supported": ["header"]
}

Copilot logs report:

Entra scope binding (strict, the default) rejected a scope whose resource does not bind to this MCP server
server_url: https://tap-mcp.core.microsoft/mcp
rejected_scope: api://727d2113-3d8f-4203-9185-4a67a67a743b/mcp.access

The CLI then intentionally refuses browser fallback. Existing cached credentials can continue working, but adding the same server as a new entry or authenticating after token removal fails.

This appears stricter than MCP/RFC requirements. MCP requires the OAuth resource parameter to identify the canonical HTTPS MCP server URI. RFC 8707 explicitly distinguishes the target resource from OAuth scopes and notes that scopes commonly describe what access is requested rather than the resource location.

This also conflicts with common Microsoft Entra API registration guidance, where delegated scopes use api://<app-id>/<scope>. Other live Microsoft MCP protected-resource metadata demonstrates that this is not specific to one server:

• Lynx (https://lynx.office.net/mcp) advertises api://3df5ed2f-8f6d-4f42-9614-454d2514cbb7/Lynx.Read.
• OCV (https://ocv.microsoft.com/ocv-gateway/mcp) advertises https://microsoft.onmicrosoft.com/OneCustomerVoice-Website-Auth-Prod/access_as_mcp, also on a different origin.
• ADO MCP advertises an origin-bound https://mcp.dev.azure.com/.default scope and is not affected by this particular check.

The process-scoped workaround suggested by the CLI logs works:

$env:COPILOT_ENTRA_ONEAUTH_SCOPE_BINDING_MODE = "allow_unbound_scopes"
copilot

That workaround weakens validation for every MCP server in the process, so it is not a suitable permanent user experience.

Could strict binding accept Entra Application ID URI scopes when they come from the HTTPS server's authoritative RFC 9728 protected-resource metadata, or provide a narrower per-server trust/configuration mechanism? At minimum, the behavior should not reject standard api:// Entra scopes without an interoperable migration path.

Relevant specifications:

• https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
• https://www.rfc-editor.org/rfc/rfc8707.html
• https://datatracker.ietf.org/doc/html/rfc9728

The issue began with fresh authentication on 1.0.92. Earlier clients/cached credentials connected successfully.

Affected version

1.0.92

Steps to reproduce the behavior

1. Use Copilot CLI 1.0.92 on Windows.
2. Configure an HTTP MCP server whose authoritative protected-resource metadata uses an Entra delegated scope in the standard api://<application-id>/<scope> format shown above.
3. Ensure no reusable credential exists, or add the server as a new entry.
4. Run Copilot and authenticate the MCP server.
5. Observe that Copilot rejects the advertised scope before launching browser sign-in.
6. Launch a new process with COPILOT_ENTRA_ONEAUTH_SCOPE_BINDING_MODE=allow_unbound_scopes and observe that authentication proceeds.

Expected behavior

Copilot should accept the delegated scope advertised by the MCP server's authoritative RFC 9728 metadata and continue the Entra authorization flow, as previous versions/cached authentication did.

If additional binding is required beyond MCP, RFC 8707, and RFC 9728, Copilot should provide a standards-compatible Entra path or a narrowly scoped per-server trust option rather than requiring a process-wide relaxation.

Additional context

• Operating system: Windows
• Shell: PowerShell
• Transport: remote Streamable HTTP MCP
• Authorization server: Microsoft Entra ID v2 endpoint
• The MCP service is healthy; this failure occurs before an authenticated request reaches it.
• The advertised scope exists and has successfully issued tokens previously.
• No tokens, user identifiers, or private log content are included in this report.