MCP OAuth authorize request omits 'scope' parameter for Entra ID servers with static oauthClientId, causing AADSTS900144

[mikemassa84]

Describe the bug

When signing in to a remote (type: http) MCP server whose authorization server is Microsoft Entra ID, configured with a statically-provided oauthClientId + oauthPublicClient: true (no Dynamic Client Registration), Copilot CLI opens the browser to Entra ID's /authorize endpoint without a scope query parameter at all, even though the server's OAuth metadata correctly advertises scopes_supported. Microsoft Entra ID's v2.0 endpoint requires scope on both the authorization request and the token exchange (unlike base RFC 6749, where it's optional), so the flow fails immediately with:

Sorry, but we're having trouble signing you in.

AADSTS900144: The request body must contain the following parameter: 'scope'.

This is very likely the same root-cause bug class as #4464 (silent refresh fails with AADSTS70011 due to mishandled scope on the refresh_token grant) — in both cases the OAuth client isn't correctly deriving/propagating the scope parameter for Entra ID flows built from server-advertised metadata. It's also functionally identical to anthropics/claude-code#69547, which reports the exact same AADSTS900144 error for the exact same scenario (pre-registered/static public client against an Entra ID-backed MCP server, since Entra ID doesn't support DCR) in a different MCP client, suggesting this is a well-known interoperability gap for MCP clients talking to Entra ID with a fixed client id.

Affected version

1.0.80 (Windows x64). Also reproduced on a locally-modified 1.0.79-era build before upgrading.

Steps to reproduce the behavior

1. Configure a remote HTTP MCP server backed by Microsoft Entra ID with a statically-provided client id (no DCR), e.g. in ~/.copilot/mcp-config.json:

  {
     "mcpServers": {
       "example-server": {
         "type": "http",
         "url": "https://example.org",
         "oauthClientId": "<entra-app-client-id>",
         "oauthPublicClient": true
       }
     }
   }

The server's /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server documents are RFC 8414-compliant: authorization_servers matches the document's own issuer exactly, and authorization_endpoint/token_endpoint point at the real Microsoft Entra ID tenant endpoints (https://login.microsoftonline.com/<tenant>/oauth2/v2.0/authorize and .../token). The authorization-server metadata's scopes_supported correctly lists the resource's App ID URI scope, e.g. ["openid", "profile", "email", "api://<app-id>/access_as_user"].
2. In the app, open MCP settings and click Sign in for that server.
3. A browser window opens and navigates to Microsoft's /authorize endpoint. The observed request URL was:

  https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize
     ?response_type=code
     &client_id=<client-id>
     &state=<state>
     &code_challenge=<challenge>
     &code_challenge_method=S256
     &redirect_uri=http%3A%2F%2F127.0.0.1%3A<port>%2F
     &client_session=<session-id>

Note there is no scope= parameter anywhere in this URL.
4. Entra ID immediately rejects the request:

   AADSTS900144: The request body must contain the following parameter: 'scope'.

Expected behavior

The MCP OAuth client should build the scope parameter for the /authorize request (and again for the /token exchange) from the target server's advertised scopes_supported (from either the oauth-authorization-server or oauth-protected-resource metadata document), the same way it presumably does for servers that use Dynamic Client Registration. For Entra ID specifically, scope must be present on every leg of the flow (authorize request, token exchange, and refresh), since Entra ID's v2.0 endpoint treats scope as mandatory rather than optional.

Additional context

• The corresponding server-side OAuth metadata was independently verified as fully RFC 8414 §3.3-compliant via repeated direct HTTP requests (issuer exactly matches authorization_servers, byte-for-byte, across 15 parallel requests) before this bug surfaced, ruling out a server-side metadata problem.
• This may be related to how the client resolves scope when a server config supplies a static oauthClientId/oauthPublicClient: true and skips the registration_endpoint (Dynamic Client Registration) flow — DCR responses may carry scope information that the static-client path doesn't otherwise obtain from scopes_supported.
• Related issues in this repo: Remote MCP OAuth: silent refresh fails with AADSTS70011 (refresh reuses granted scope mixing .default + resource-specific scopes), forcing repeated interactive sign-in #4464 (refresh-token grant mishandles Entra ID scope, AADSTS70011), Copilot CLI 1.0.79 rejects GitLab MCP OAuth metadata with an RFC 8414 issuer mismatch #4439 / Atlassian MCP OAuth fails with "Incompatible authorization server (RFC 8414 §3.3)" on 1.0.79 — regression from 1.0.71 #4480 (separate RFC 8414 issuer-mismatch bugs, now fixed/in progress).
• Related issue in a different MCP client with an identical error and scenario: OAuth token exchange fails with AADSTS900144 (missing 'scope') when using --client-id for Entra ID MCP server anthropics/claude-code#69547.

[mikemassa84]

---

Update: we root-caused this further on our end. Our MCP server's 401 response was missing a scope
auth-param on its WWW-Authenticate challenge header — it only sent resource_metadata:

WWW-Authenticate: Bearer resource_metadata="https://mcp.bld.nm.org/.well-known/oauth-protected-resource"

Adding scope directly to that header (per RFC 6750 §3, which allows a scope auth-param on the
challenge) immediately fixed sign-in on our end, with no client-side change:

WWW-Authenticate: Bearer resource_metadata="https://mcp.bld.nm.org/.well-known/oauth-protected-resource", scope="api://<our-client-id>/access_as_user"

This points to a more precise root cause than we originally reported: it looks like Copilot CLI's MCP OAuth
client (the rmcp-based transport) derives the scope parameter for the /authorize request directly
from the scope auth-param on the initial 401 WWW-Authenticate challenge header, rather than falling
back to scopes_supported in the oauth-authorization-server / oauth-protected-resource discovery
documents when that header omits scope. In our case, scopes_supported was correctly populated in both
discovery documents the whole time — the client just never appears to consult it as a fallback source for
scope on the authorize request.

So this is being resolved on our side by adding the scope auth-param to our challenge header (a spec-legal,
if previously-omitted, practice). But it may still be worth hardening the client: any RFC 8414/9728-compliant
MCP server whose 401 challenge doesn't happen to include a scope auth-param (arguably still a valid,
minimal configuration) will hit this exact same failure today, since apparently only the challenge header is
consulted and not the fuller discovery metadata. A fallback to scopes_supported from the authorization
server or protected-resource metadata when the challenge header omits scope would make the client more
robust against this class of server configuration.

[pamelasb447]

I don't know what I'm doing.

…

On Mon, Aug 24, 2026, 7:26 AM Michael Massa ***@***.***> wrote: *mikemassa84* left a comment (github/copilot-cli#4582) <#4582 (comment)> ------------------------------ Update: we root-caused this further on our end. Our MCP server's 401 response was missing a scope auth-param on its WWW-Authenticate challenge header — it only sent resource_metadata: WWW-Authenticate: Bearer resource_metadata="https://mcp.bld.nm.org/.well-known/oauth-protected-resource" Adding scope directly to that header (per RFC 6750 §3, which allows a scope auth-param on the challenge) immediately fixed sign-in on our end, with no client-side change: WWW-Authenticate: Bearer resource_metadata="https://mcp.bld.nm.org/.well-known/oauth-protected-resource", scope="api://<our-client-id>/access_as_user" This points to a more precise root cause than we originally reported: it looks like Copilot CLI's MCP OAuth client (the rmcp-based transport) derives the scope parameter for the /authorize request *directly from the scope auth-param on the initial 401 WWW-Authenticate challenge header*, rather than falling back to scopes_supported in the oauth-authorization-server / oauth-protected-resource discovery documents when that header omits scope. In our case, scopes_supported was correctly populated in both discovery documents the whole time — the client just never appears to consult it as a fallback source for scope on the authorize request. So this is being resolved on our side by adding the scope auth-param to our challenge header (a spec-legal, if previously-omitted, practice). But it may still be worth hardening the client: any RFC 8414/9728-compliant MCP server whose 401 challenge doesn't happen to include a scope auth-param (arguably still a valid, minimal configuration) will hit this exact same failure today, since apparently only the challenge header is consulted and not the fuller discovery metadata. A fallback to scopes_supported from the authorization server or protected-resource metadata when the challenge header omits scope would make the client more robust against this class of server configuration. — Reply to this email directly, view it on GitHub <#4582?email_source=notifications&email_token=CMNMA4YL4CSE3JKWIOIQ3PL5LRGCJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZZGY3DEMBUG4YKM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-5396620470>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CMNMA44LFSB7GNXNEBPNEGL5LRGCJAVCNFSNUABFKJSXA33TNF2G64TZHM2TQNJYGYYDMNRUHNEXG43VMU5TKMRTGUYDENBWGI22C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CMNMA47MFRGC6WUBOZF2SLT5LRGCJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZZGY3DEMBUG4YKM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CMNMA45K2C74BYAGIMK2LOT5LRGCJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZZGY3DEMBUG4YKM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>