MCP OAuth against Microsoft Entra ID: AADSTS9010010 on connect, AADSTS650053 on reconnect (dup of closed #73460 / #76096)

Reopening this as a fresh issue per the stale-bot's own instruction on #73460, which was auto-closed for inactivity before getting any traction, and its duplicate #76096, also closed. The underlying defect is still live as of Claude Code 2.1.241 (2026-08-25) — confirmed today against a real Entra-protected MCP server on Azure App Service, not a synthetic repro.

Original defect, still reproducing: resource=<server URL> sent to Entra's /authorize → AADSTS9010010, because Entra requires resource to byte-match the app's api://<app-id> identifier while Claude Code's RFC 9728 check requires resource to match the server's own canonical URL. Full detail in #73460 and #76096.

New: a second, distinct manifestation on reconnect, not just initial connect. Both Claude Code's /mcp and Claude Desktop's custom-connector "Reconnect" produced:

AADSTS650053: The application '<app>' asked for scope 'mcp.read' that doesn't exist
on the resource '00000003-0000-0000-c000-000000000000'.

00000003-0000-0000-c000-000000000000 is Microsoft Graph's well-known app ID. Whatever request path a reconnect/refresh takes appears to drop the resource/scope qualification entirely, and Entra silently defaults to Graph. This surfaces with no Entra-branded error page and no actionable detail — just a generic client-side "Authorization failed" — so it's easy to mistake for a separate bug rather than the same root cause on a different path.

A concrete data point for the fix. We bypassed Claude's client entirely (MSAL device-code flow, direct to Entra) to confirm our server was correct, and decoded the resulting token:

aud: <bare-app-id-guid>        ← no "api://" prefix

— identical regardless of whether the scope was requested in the api://<app-id>/scope form or the resource-URL form. When the client and the resource are the same app registration (the common single-app MCP pattern), Entra collapses aud to the bare GUID, not api://<guid>. Whatever fix lands here, the resource-server side of any reference implementation will need to accept that bare-GUID audience too — we had to add it as a third accepted value on our own API before a manually-obtained token would validate.

Happy to share our exact repro steps/config if useful.