Entra ID (v2.0): authorize request rejected with AADSTS9010010 when scopes_supported advertises short scope names — fully-qualified scope confirmed as fix

### MCP server URL

https://mcp.example-corp.com/api/mcp

### Where does the issue occur?

When pressing the Connect button

### Transport used

streamable-http

### Client registration type

Static

### SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

### When did you last reproduce this?

2026-09-02, ~12:26–12:30 PM EDT (16:26–16:30 UTC). Note: the issue is now worked around on our server (see details), so the live connector currently succeeds. Reverting scopes_supported to the short form reproduces the failure deterministically.

### Browser and OS

macOS (Sequoia). Reproduced identically in Safari (claude.ai web) and the Claude desktop app.

### Describe the issue

Adding a custom connector backed by Microsoft Entra ID (v2.0 endpoint,
cross-host authorization server per RFC 9728) failed before any
Microsoft sign-in screen appeared. Claude's error URL carried
oauth_error_subtype=provider_redirect and entra_aadsts_code=9010010
("The resource parameter provided in the request doesn't match with
the requested scopes"). No sign-in log entry was created on the Entra
side — the authorize request itself was rejected on arrival.

Error references shown in Claude.ai: ofid_11f4ba692b201afb and
ofid_6d86bec137cbdc58. Entra trace IDs:
5254997e-4aa6-429f-81d6-2aced2791b00 and
8d4b6cf6-37e3-435f-bd55-7c1b2ba91900.

Our configuration at the time: Application ID URI registered EXACTLY
as the MCP URL (https://mcp.example-corp.com/api/mcp, no trailing
slash), delegated scope Tasks.Read exposed and admin-consented,
pre-registered confidential client with the claude.ai redirect URI,
and protected-resource metadata advertising scopes_supported:
["Tasks.Read"] (short form).

Root cause as far as we can tell: Entra v2.0 recently tightened
validation and rejects authorize requests where the RFC 8707 resource
parameter (which the MCP spec mandates and Claude always sends) does
not resolve to the same app registration as the requested scope. Entra
never implemented RFC 8707; a short scope name resolves to no app, so
the request fails. Related reports across the ecosystem:
microsoft/powerbi-modeling-mcp#68, microsoft/azure-devops-mcp#1293,
microsoft/Dataverse-MCP#15, IBM/mcp-context-forge#2881,
microsoft/vscode#321249, anthropics/claude-code#55993.

CONFIRMED WORKAROUND: changing scopes_supported to the
fully-qualified form that resolves to the same app registration as
the resource — https://mcp.example-corp.com/api/mcp/Tasks.Read —
made the exact same connector complete the OAuth flow end to end
(sign-in, consent, connected, tool discovered, authenticated tool
call succeeding in production).

### Issue details

```shell
Pop-up error shown in Claude.ai (both web and desktop app):

"Authorization with App To-Do failed. You can check your
credentials and permissions. Entra Trace ID:
8d4b6cf6-37e3-435f-bd55-7c1b2ba91900. If this persists, share this
reference with support: 'ofid_6d86bec137cbdc58'"

A second attempt produced the same toast with Entra Trace ID
d3952adb-032b-45e4-901a-7e2eaf7c1e00 and reference
"ofid_bb26bd1392f9b395".

The desktop app's error redirect URL exposed the underlying cause:

.../chat/...?&mcp_auth_source=settings_connect
&server=78992652-d008-4584-a66a-a25a9a5d11ac
&step=end_error
&flow_id=ofid_11f4ba692b201afb
&oauth_error=non_standard
&oauth_error_subtype=provider_redirect
&entra_aadsts_code=9010010
&entra_trace_id=5254997e-4aa6-429f-81d6-2aced2791b00

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

No Microsoft sign-in screen ever appeared, and no sign-in log entry
was created in the Entra tenant (checked interactive and
non-interactive logs) — the authorize request was rejected on arrival
at the authorization server, before user authentication.

With scopes_supported changed to the fully-qualified
https://mcp.example-corp.com/api/mcp/Tasks.Read (same connector,
same client, no other change), the flow completed successfully:
Microsoft sign-in appeared, consent granted, connector connected,
whoami tool discovered and called successfully with the resolved
user identity.
```

### Expected behavior

Either the connector flow succeeds with a short scope name (e.g. by
Claude fully-qualifying short scopes against the resource for
identity providers known not to support RFC 8707), or the
connector-building docs' Entra section documents that scopes_supported
must advertise fully-qualified scope strings resolving to the same app
registration as the resource. The docs currently cover the Application
ID URI / AADSTS9010010 trap but not the scope form, and the error
surfaced in Claude.ai does not hint at the scope being the problem.

### Logs from your server

```shell
Nothing relevant — the failure occurs at the authorization server
before any request reaches our MCP endpoint. Our server's 401
challenge and RFC 9728 metadata were verified correct and are served
directly (HTTP/2 via Railway, no redirect).
```

### Additional context

OAuth provider: Microsoft Entra ID, single tenant, v1.0 access tokens
(requestedAccessTokenVersion: null). Authentication: "Always required",
"Use your own OAuth client" with client secret. Transport: streamable
HTTP at a single /api/mcp endpoint (mcp-handler 2.x on Next.js App
Router). The tenant does not advertise code_challenge_methods_supported
(Entra never does), which per your docs Claude tolerates — confirming
that was fine; the scope/resource mismatch was the only blocker. Happy
to provide more traces or run test builds.

Note: the server URL above is a placeholder (redacted). The flow_id /
ofid references identify the real flows on your side; happy to share
the actual URL privately if needed.