[Bug]:Remote MCP server OAuth flow broken — AADSTS9010010: `resource` parameter conflicts with `scope` on v2.0 endpoint

[lei-liu]

Version

Remote Power BI MCP Server — https://api.fabric.microsoft.com/v1/mcp/powerbi

Model used

Claude Sonnet 4.6 (via GitHub Copilot CLI v1.0.2)

Description

The Remote Power BI MCP server's browser-based OAuth authentication flow stopped working around March 7–8, 2026. The authorization URL constructed by the server sends both a scope and a resource parameter on the OAuth v2.0 endpoint. This combination is invalid on v2.0 and now triggers AADSTS9010010 due to a Microsoft Entra ID enforcement change rolled out in early March 2026.

The v2.0 endpoint does not support the resource parameter (Microsoft docs). Azure AD previously tolerated this parameter silently, but stricter validation now rejects any request where resource conflicts with or duplicates the scope value.

The problematic authorization URL constructed by the server:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
  response_type=code&
  client_id=aebc6443-996d-45c2-90f0-388ff96faa56&
  code_challenge=RLVE6Q5yxa2kgoIBUD1FN5_Y_PKqAA9C-cqW8C2ju7w&
  code_challenge_method=S256&
  redirect_uri=http://127.0.0.1:50389/&
  state=XOzIbjumFRWmQmrNu226Z8O29x6qt-dlakQ5MYOmISY&
  scope=https://analysis.windows.net/powerbi/api/.default&
  resource=https://api.fabric.microsoft.com/v1/mcp/powerbi

Parameter	Value	Issue
scope	https://analysis.windows.net/powerbi/api/.default	✅ Correct for v2.0
resource	https://api.fabric.microsoft.com/v1/mcp/powerbi	❌ Not supported in v2.0; mismatched resource

Expected Behavior

The server initiates the browser OAuth flow, the user authenticates successfully, and the MCP client connects to https://api.fabric.microsoft.com/v1/mcp/powerbi with a valid token.

The OAuth v2.0 authorization request should include only the scope parameter. The resource parameter must be removed from the request.

Actual Behavior

The browser redirect to Azure AD returns:

AADSTS9010010: The resource parameter provided in the request doesn't match with the requested scopes.

Authentication never completes, and the MCP client reports:

MCP error -32001: Request timed out

Reproduction steps:

1. Configure the Remote Power BI MCP server in any MCP client (no headers / pre-auth):

   {
     "powerbi-remote": {
       "url": "https://api.fabric.microsoft.com/v1/mcp/powerbi",
       "type": "http"
     }
   }

2. Attempt to connect — the server initiates the browser OAuth flow.
3. Browser shows the AADSTS9010010 error; authentication never completes.
4. MCP client reports: MCP error -32001: Request timed out

Additional Context

• OS: Windows 11
• Tenant: Microsoft corp (72f988bf-86f1-41af-91ab-2d7cd011db47)
• Date broken: ~March 7–8, 2026 (worked fine the prior week)
• Screenshot: [Screenshot 2026-03-09 154643.png] showing AADSTS9010010 in browser

[adriandsa]

I am seeing the same issue in one of my mcp servers. Does anyone know the solution?

[stephengodderidge]

Hey Lei Liu (@lei-liu), the GitHub Copilot CLI update caused a bug where that error is shown .

It should be resolved now. I verified this morning with v1.0.5. You may need to update your GitHub CLI version (run /update with Copilot open).

Can you let me know if you're still seeing issues?

[stephengodderidge]

adriandsa is your issue also with the GitHub Copilot CLI and a separate MCP server?

[FranFdezColoma]

Stephen Godderidge (@stephengodderidge) I am having exactly the same problem with the Dataverse MCP server for Github Copilot CLI ( 1.0.7), token expires after 1 hour and does not refresh correctly

Tools: AADSTS9010010: The resource parameter provided in the request doesn't match with the requested scopes.

[naqvir90]

I am having this error too, when testing oauth flow in the mcp inspector using . I want to add, when i use postman, it doesnt add the resource parameter and it works fine.

[ericchansen]

Adding concrete data from the Copilot CLI side.

Stephen Godderidge (@stephengodderidge) mentioned this was fixed in CLI v1.0.5, but Francisco Fernandez Coloma (@FranFdezColoma) and naqvir90 are still hitting it. I believe the root cause is server-side, not CLI-side.

We confirmed that the Power BI Remote server is the only MCP server (out of 7 configured) that triggers a browser auth prompt on every CLI session start. Tested by launching with --disable-mcp-server powerbi-remote — popup disappears completely.

Inspecting the CLI's cached OAuth metadata (~/.copilot/mcp-oauth-config/), the Power BI Remote server includes a resourceUrl field that other servers (e.g., Dataverse MCP) do not:

Field	Power BI Remote	Dataverse MCP
resourceUrl	https://api.fabric.microsoft.com/v1/mcp/powerbi	(not present)
authorizationServerUrl	/common/v2.0	/<tenant-id>/v2.0

This resourceUrl is what gets sent as the resource parameter in the v2.0 authorization URL — the direct cause of AADSTS9010010. The Dataverse MCP server omits this field and its auth works silently.

The CLI does cache a refresh token for Power BI (1,743 chars), but it appears the silent token refresh path also fails — likely because the refresh request includes the same invalid resource parameter — forcing a full browser flow every time.

Suggested fix: Remove resourceUrl from the Power BI Remote server's OAuth discovery response, matching the pattern used by Dataverse MCP.

Workaround: --disable-mcp-server powerbi-remote when launching the CLI.

Related: microsoft/mcp#1922 (tracking the startup prompt UX issue).

[mfernandezfidesol]

same problem here with claude desktop

[AviHack]

Affected client: Claude Cowork (Anthropic desktop app)

Confirming this issue. When adding https://api.fabric.microsoft.com/v1/mcp/powerbi as a custom remote MCP connector in Claude Cowork, clicking Connect immediately returns "Couldn't reach the MCP server" — no sign-in prompt appears at all.

The tenant setting "Users can use the Power BI Model Context Protocol server endpoint (preview)" is enabled for the entire organization, so that's not the blocker.

Based on the diagnosis in this thread, the resourceUrl field in the OAuth discovery response is causing the auth flow to fail before it even reaches the sign-in step. This affects Claude Cowork users the same way it affects GitHub Copilot CLI users.

+1 on the fix: removing resourceUrl from the discovery response to match the Dataverse MCP pattern.

[drathore-upland]

We are seeing the same issue in an integration with Amazon QuickSight and Azure AD (Entra ID).

QuickSight generates the authorize URL and includes both:

scope=api:///SH.ALL (v2 style)
resource= (v1 style)

against the /oauth2/v2.0/authorize endpoint, which results in:

AADSTS9010010: The resource parameter provided in the request doesn't match with the requested scopes

From what we can tell, this appears to be due to stricter validation in Azure AD, since the v2 endpoint expects scope and does not support resource in the same request. ()

The challenge is that we don’t control the final authorize URL—QuickSight constructs it internally—so we cannot remove the resource parameter.

Questions:

Has there been a recent enforcement change around rejecting resource + scope on v2 endpoints?
Is there any backward compatibility or mitigation planned for third-party tools that still send resources?
Any recommended approach for integrations where the OAuth request cannot be fully controlled?

This seems like a broader compatibility issue affecting tools that haven’t fully migrated to pure v2 semantics.

[LlewellynS96]

Confirming we're hitting this too. First-time setup, never worked for us. Tenant setting is enabled.

Connecting from the claude.ai connector against https://api.fabric.microsoft.com/v1/mcp/powerbi gives us one of two errors:

1. Couldn't connect Microsoft Power BI — Failed to generate authorization URL
2. Couldn't reach the MCP server

Any ETA on a fix or workaround?

[isabellec23]

Hitting the same AADSTS9010010 error connecting Claude.ai (web) to a Fabric Data Agent MCP endpoint - not just Power BI MCP. Same root cause: resource parameter on Entra v2 endpoint.
Endpoint pattern: https://api.fabric.microsoft.com/v1/mcp/workspaces/{id}/dataagents/{id}/agent