[BUG] MCP OAuth appends trailing slash to `resource` parameter, breaking Entra ID auth (AADSTS9010010)

I also found this bug and it would be very nice if it can be solved asap.

I've issues with this aswel

Confirming this on Claude.ai web (Team workspace) Custom Connector with Microsoft Entra ID.

Setup: MCP server on Azure Functions at https://<app>.azurewebsites.net/mcp behind App Service Authentication (Easy Auth) configured for Microsoft Entra. Single-tenant Entra app with App ID URI api://<client-id>. I can't add the actual MCP URL as a second App ID URI because Entra requires identifier URIs to be on a verified domain of the tenant, and azurewebsites.net is owned by Microsoft, not us. The /.well-known/oauth-protected-resource document declares "resource": "api://<client-id>" and "scopes_supported": ["api://<client-id>/mcp.access"].

When I click Add on the connector, I never even see the Microsoft sign-in page it errors out before that. The redirect URL is:

https://claude.ai/api/mcp/auth_callback?error=invalid_target&error_description=AADSTS9010010%3a+The+resource+parameter+provided+in+the+request+doesn%27t+match+with+the+requested+scopes.+Trace+ID%3a+8f26a744-b393-4350-9974-203f31ad1600

Per AADSTS9010010, Entra compares the resource parameter against the scope's implicit resource (everything before the final slash) and rejects on mismatch. The trailing slash Claude appends turns api://<client-id> into api://<client-id>/, which no longer equals the scope's resource portion api://<client-id>.

Microsoft's documented workaround for this is to put Azure API Management with a verified custom domain in front of the Function App, register that as the Entra App ID URI, and proxy through it (https://developer.microsoft.com/blog/claude-ready-secure-mcp-apim). That's significant infrastructure overhead just to work around the trailing slash.

Could you strip the trailing slash from the resource parameter before sending it to the authorization server? In its current form this breaks every Entra-protected MCP that doesn't have a verified custom domain available.

Also problematic for me

having the same issue

I'm having the same issue.

This is also issue for me, any fix?

Ref: ofid_c51480b27686441a
Since #55993 has been marked as a duplicate of this one and closed, I'm adding a related case from Claude Cowork (claude.ai web connector) where resource and scope do not match — not because of a trailing slash, but because the AzDo MCP server's OAuth metadata advertises a GUID-based scope that is unrelated to the MCP server URL:

resource: https://mcp.dev.azure.com/<org> (MCP server URL, passed by Claude)
scope: 2a72489c-aab2-4b65-b93a-a91edccf33b8/.default (AzDo MCP service principal, from resource metadata)

Entra returns AADSTS9010010. Manually removing resource= from the authorization request results in Entra issuing a valid code at https://claude.ai/api/mcp/auth_callback?code=..., confirming resource= is the sole cause.

The MCP specification is clear: 8.1 Canonical URL​

Note: While both https://mcp.example.com/ (with trailing slash) and https://mcp.example.com (without trailing slash) are technically valid absolute URIs according to RFC 3986, implementations SHOULD consistently use the form without the trailing slash for better interoperability unless the trailing slash is semantically significant for the specific resource.

Claude Code SHOULD be following the standard that Anthropic created.

Adding a +1 to this thread too. We're building out a custom MCP server backed by EntraID and am getting the same error when trying to connect via Claude Web/Desktop. The Azure API Manager is seriously overkill for this.

Worked around this for Microsoft Entra ID after running into AADSTS9010010 ("resource parameter doesn't match the requested scopes"). Posting our notes in case it saves someone the day of debugging.

Root cause — in selectResourceURL:

authorizationUrl.searchParams.set('resource', resource.href);

URL.href runs WHATWG normalization, which appends / to bare-origin URLs (new URL("https://example.com").toString() === "https://example.com/").

The broken round-trip, concretely. Server publishes:

// GET https://example.com/.well-known/oauth-protected-resource
{
  "resource": "https://example.com",
  "authorization_servers": ["https://login.microsoftonline.com/<tenant>/v2.0"],
  "scopes_supported": ["https://example.com/access_as_user"]
}

Server's 401 challenge points the client at that document:

WWW-Authenticate: Bearer error="invalid_token",
  resource_metadata="https://example.com/.well-known/oauth-protected-resource"

SDK fetches the document, sees resource = "https://example.com", runs it through URL.href → "https://example.com/", and forwards:

.../authorize?...
  &scope=https%3A%2F%2Fexample.com%2Faccess_as_user
  &resource=https%3A%2F%2Fexample.com%2F

Entra now sees resource=https://example.com/ (with slash), but the prefix of the scope (https://example.com/access_as_user → https://example.com) has no slash. Verbatim prefix check fails → AADSTS9010010.

What didn't work for us:

1. Add a trailing slash to the identifier URI on the Entra app (https://example.com/). Entra refuses identifier_uris with trailing slashes outright — not configurable.

1. Switch the resource namespace to api://<guid>. Non-special URL schemes survive URL.href untouched (no trailing-slash mutation), and Entra is happy with api://<guid> natively since every app reg gets one as the default App ID URI. But:

• The SDK's checkResourceAllowed (src/shared/auth-utils.ts) compares requested.origin !== configured.origin, and non-special-scheme URLs have a null origin in WHATWG — so the SDK throws Protected resource api://<guid> does not match expected https://example.com/path (or origin) and never sends the request.
• Independently, RFC 9728 §3.3 requires the OPRM document's resource to be verifiable against the URL the client was attempting to access. Swapping schemes mid-flight isn't spec-compliant.

1. What actually works: register a secondary https:// identifier URI on the Entra app with a non-trivial path (e.g. https://example.com/mcp). Advertise that URL as resource in the OPRM document and as the prefix in scopes_supported. Non-empty paths survive URL.href unchanged, so both Entra's prefix check and the SDK's origin check pass. Same aud=<client-id> in issued tokens, so resource-server JWT validation is unaffected. resource_metadata in the WWW-Authenticate header can (and should) still point at the host-root well-known location — that's an independent URL.

Working configuration (sanitized to example.com, but this is the actual shape running in production for us):

// GET https://example.com/.well-known/oauth-protected-resource
{
  "resource": "https://example.com/mcp",
  "authorization_servers": ["https://login.microsoftonline.com/<tenant>/v2.0"],
  "scopes_supported": ["https://example.com/mcp/access_as_user"],
  "bearer_methods_supported": ["header"]
}

HTTP/2 401
WWW-Authenticate: Bearer error="invalid_token",
  error_description="An error occurred while attempting to decode the Jwt: Malformed token",
  error_uri="https://tools.ietf.org/html/rfc6750#section-3.1",
  resource_metadata="https://example.com/.well-known/oauth-protected-resource"

Note the /mcp path on resource and inside scopes_supported, contrasted with the host-root resource_metadata URL — those two URLs don't need to be the same, and in fact must differ if resource carries a path.

Server-side workaround, not a Claude Code / SDK fix — but it unblocks Entra-backed MCP servers today. The underlying bug is the SDK treating the OPRM document's resource as round-trippable text while quietly putting it through URL.href; either stop normalizing, or stop sending resource whose normalized form differs from scopes_supported's prefix.

+1 same issue for me

+1, same issue here

+1. Seems like it's an easy fix. Not sure why it's taking a month to move on it.

+1, same issue here

+1, same issue here

Confirming this same bug on Claude Code v2.1.x against the Azure DevOps remote MCP server
(https://mcp.dev.azure.com/<org>) — different MCP server than the original report, identical failure mode:

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

The server's oauth-protected-resource metadata declares:
{
"resource": https://mcp.dev.azure.com/<org>,
"scopes_supported": ["<entra-app-guid>/.default"]
}

Wireshark/redirect inspection confirms Claude Code emits resource=https://mcp.dev.azure.com/<org>/ with a trailing
slash, matching the reporter's diagnosis.

A useful additional data point for whoever picks this up: the bug is silent when the advertised scope is URL-prefixed
({resource}/.default) but visible when the scope is GUID-prefixed ({guid}/.default). With a URL-prefixed scope (e.g.
Microsoft 365 Copilot agent MCPs), Entra's resource-vs-scope comparator passes because the scope literally starts with
the mangled resource string. With a GUID-prefixed scope, Entra has to resolve the GUID to the App ID URI and
string-compare against the slashed resource — and rejects. This means a fix would unblock GUID-scope servers like ADO
without changing behavior for the URL-scope ones that happen to work today.

Reproduction is not platform-specific — hitting this on Linux (WSL2) (just noting since this has platform:macos label)

Workaround in use: headersHelper invoking az account get-access-token --resource <guid> and emitting {"Authorization":
"Bearer ..."}. Stable but requires az and a separate az login session.

Tried the oauth.scopes override (replacing the discovered GUID scope with the URL form {resource}/.default) as a
config-only sidestep. That avoids 9010010 but Entra then fails with AADSTS500011: The resource principal was not found
in the tenant because URL-form scopes require a service principal in the consuming tenant, which the ADO MCP backing
app doesn't have. So scopes override is not a viable workaround for this server class.

Claude code used in drafting this comment

I hit a similar Entra OAuth mismatch once, the authorize step looked fine until one normalized resource string drifted from the metadata. Since your repro already proves the protected-resource metadata omits the trailing slash while both /authorize and /token add it back, I'd diff those exact resource values before touching scopes again. My usual checks are a raw manual diff, authproxy.dev if I need to inspect the handoff, or OAuth Redirect Doctor when I want resource URI, callback path, and provider expectations lined up. ngl one auto-added slash is enough to make Entra treat it as a different resource.

@whiskeysierra thank you so much. This worked for us.

+1, same issue here

+1, same issue here

+1 trailing slash is blocking us

+1 same issue

+1, same impact on our side.

We worked around it by putting a small OAuth compatibility proxy in front of Entra. It publishes its own discovery metadata, forwards /authorize and /token to the tenant-specific Entra v2 endpoint, and removes only the resource parameter before forwarding.

Important detail from our setup: stripping resource only during /authorize was not enough - it also had to be removed during the /token exchange.

I published a sanitized example here:
https://gist.github.com/matzegebbe/fba6417a81cc692eca64d0244512b066

+1 same issue

+1 this is blocking us and preventing a full migration to Claude.

We can't have all the domains verified on our tenant, because some of those domains are also local domains. Claude Code should not send the resource parameter, or at least should do what Copilot already does, which works out of the box.

Reproducing on Microsoft Fabric MCP Server (Windows, Claude Code v2.1.191 + claude.ai web)

Affected endpoints:

• Fabric Core MCP: https://api.fabric.microsoft.com/v1/mcp
• Fabric Data Agent MCP: https://api.fabric.microsoft.com/v1/mcp/workspaces/{workspace-id}/dataagents/{agent-id}/agent

Environment:

• Platform: Windows 11
• Claude Code version: v2.1.191 (latest as of 2026-06-25)
• Also reproduced on claude.ai web connector (same error)
• Entra tenant: single-tenant, Microsoft Entra ID

Error observed:

Authorization with the MCP server failed. You can check your credentials and permissions.
Entra Trace IDs: b9729652-bd65-49d9-b32c-9d5f5f0d4500, d7cf68c1-8184-4b64-b612-0f8c12481900
ofid references: ofid_43c91433f910864b, ofid_c1114c29671b0a1f, ofid_16bbfa64b85c7ca1, ofid_c69ca4f1994091b0

Confirmed via Entra non-interactive sign-in logs:

Sign-in error code: 9010010
Failure reason: The resource parameter provided in the request doesn't match with the requested scopes.
User agent: python-httpx/0.28.1
Client credential type: Client secret

Key observations:

• Interactive sign-in logs show Success — user authenticates fine against Power BI Service
• Non-interactive sign-in logs show Failure with AADSTS9010010 — the OBO token exchange from Anthropic's backend (python-httpx/0.28.1) fails
• Conditional Access is not the issue — CA shows "Not applied" on the failed entry
• App registration has correct delegated permissions: Item.Read.All, Workspace.Read.All both granted with admin consent
• Both redirect URIs registered: https://claude.ai/oauth/callback and https://claude.ai/api/mcp/auth_callback
• Issue persists on latest Claude Code version (v2.1.191) — not fixed by updating

This is consistent with the trailing slash / v1 resource parameter bug described in this issue and #55993. The fix needs to be on Anthropic's backend — the resource parameter being sent to Entra's v2 endpoint is either malformed or mismatched against the scope prefix.

Please prioritize — this blocks all Microsoft Fabric MCP connections for Entra-protected tenants.

just lost most of my day to trying and failing to fix this exact problem. Wish i had found this first. Please fix :(

⏫ this needs to be fixed!

we're blocked by this in production

We hit this exact failure mode (AADSTS9010010: The resource parameter provided in the request doesn't match with the requested scopes) building a production MCP integration for a financial services firm, fronting a custom MCP server with Azure API Management for Entra ID authentication. Landed here via #55993 → this issue.
Setup: APIM-fronted MCP server, validate-jwt policy, PRM correctly published at /.well-known/oauth-protected-resource, Entra v2 app registration with a custom API scope (api://{app-id}/access_as_user).
Confirmed via mcp-remote (v0.1.38) with --debug:

No --resource flag → auto-derives resource from the MCP server URL, mismatches the API's audience → AADSTS9010010
--resource explicitly set to match the audience → authorize step succeeds, but token exchange still fails with the identical error
No flag combination in 0.1.38 allows omitting the resource parameter entirely

Cross-client confirmation: the official @modelcontextprotocol/inspector (a separate, independent client) hits the identical failure against the same endpoint — rejected at the authorize step rather than token exchange.
Relevant to this specific issue's root cause: I want to flag that in our case, the resource value used matched our PRM's declared resource exactly, character-for-character (no trailing-slash discrepancy on either side) — so if the trailing-slash normalization bug described here is the sole cause, that wouldn't explain our failure. Wondering if this represents a second, distinct trigger for the same AADSTS9010010 error rather than the same root cause — happy to share sanitized --debug logs and the exact authorize/token URLs we captured if that'd help distinguish the two.

Adding an independent production repro with one point I don't think has been made explicitly in this thread: for the common case, no server-side configuration can work around this, by Microsoft's own rules.

Setup: custom MCP resource server (FastMCP over Streamable HTTP on Azure Container Apps), single-tenant Entra, pre-registered public client (authorization-code + PKCE, no DCR), RFC 9728 PRM served correctly, resource advertised without a trailing slash. Both Claude Code (v2.1.179) and the claude.ai / Claude Desktop custom connector sign in successfully, then fail at the authorization request with AADSTS9010010 (confirmed in the Entra sign-in log, errorCode 9010010).

Why there is no workaround for host-root resources:

1. Entra rejects an authorization request carrying both an RFC 8707 resource and a v2 scope unless the resource exactly matches the App ID URI the scope belongs to (that is what AADSTS9010010 is).
2. Microsoft's identifier URI restrictions state: "The application ID URI value must not end with a slash." (https://learn.microsoft.com/en-us/entra/identity-platform/identifier-uri-restrictions)
3. Claude's OAuth client appends a trailing slash to host-root resource URIs (the selectResourceURL URL-normalisation noted above).

So the slashed value Claude sends can never equal any App ID URI Entra will accept. We verified the "verified custom domain" route specifically: tenant-verified domain, https:// App ID URI permitted and ready to set, and it still cannot help, because the URI cannot carry the trailing slash the client insists on. The spec note quoted earlier in the thread already says implementations SHOULD use the un-slashed form; using the PRM resource value verbatim would fix this.

Impact for us: our public MCP ships unauthenticated, and an Entra-authenticated MCP for future workloads is procedurally ready and blocked solely on this.

There is a workaround. Did you read my comment earlier in this thread? If
you register your identifier URI with a path, e.g. /mcp then it works.
You are correct in "no workaround for host-root resources" exist.

There is a workaround. Did you read my comment earlier in this thread? If you register your identifier URI with a path, e.g. /mcp then it works. You are correct in "no workaround for host-root resources" exist.

@whiskeysierra apologies, I'd missed the pathed-URI detail. Thanks for the correction and for the full working configuration; it is the probably most useful thing in this thread. The subtleties of resource_metadata staying at the host-root well-known while resource carries the path is what got us unblocked.

The SDK fix is still needed for host-root servers (including Microsoft's own, which can't change their canonical URIs), but agreed: custom Entra-backed servers are unblockable today with your configuration. 😃

Same here with the latest preview.

Confirming this from a different deployment shape: an MCP gateway/registry that fronts many MCP servers behind a single Entra tenant (agentic-community/mcp-gateway-registry, tracked on our side under #990 and related Entra IDE-login work). We hit the identical AADSTS9010010 at token exchange.

A data point that corroborates the WHATWG-normalization root cause and doubles as a workaround for anyone stuck:

• When our PRM advertises a bare-origin resource (https://gw, no trailing slash, verified via curl), Claude Code sends resource=https://gw/ on /authorize (origin + appended /). Entra can never match this, because App ID URIs must not end in a slash and Entra compares resource against identifierUris by exact string. Bare-origin resource is therefore unresolvable on Entra on both sides at once.
• When we instead advertise a path-qualified resource (https://gw/<server>/mcp), Claude Code sends it verbatim with no appended slash, and login succeeds. This is consistent with the root cause: URL.href only appends / to a path-less URL, so a resource that already carries a path round-trips unchanged.

So the path-qualified form is a viable server-side workaround today, but it has a real cost that the verbatim fix would eliminate: because the origin can't be used, each MCP server needs its own path-qualified identifierUri in Entra (bumping against Entra's 999-URI-per-app cap), instead of registering the origin once for the whole gateway. Fixing the SDK to emit the PRM resource verbatim would collapse this back to a single origin registration.

Strong +1 on the proposed fix: preserve the metadata resource string verbatim and do not round-trip it through URL. Both emission points (/authorize query param and /token body param) need it.

cc @omrishiv

---

Update: the root cause lives in the MCP TypeScript SDK, not Claude Code itself — selectResourceURL in packages/client/src/client/auth.ts returns new URL(resourceMetadata.resource), and URL.href is what appends the slash. Tracked upstream as modelcontextprotocol/typescript-sdk#1968, with a fix in modelcontextprotocol/typescript-sdk#1991 that preserves the metadata resource verbatim (we reviewed it and endorsed it here). Claude Code picks the fix up once it bumps the SDK dependency.

@aarora79 Isn't this exactly the workaround I described in https://github.com/anthropics/claude-code/issues/52871#issuecomment-4602137405?

@whiskeysierra, it is, but we need this fixed so that we dont have to put this workaround in our MCP Gateway Registry code and then take care of all the downstream consequences such as adding an identifierUri for each of the MCP server registered with our Gateway, and even that approach would break when we reach 999 registered servers. The fix actually is covered by this PR https://github.com/modelcontextprotocol/typescript-sdk/pull/1991 on the MCP Typescript SDK repo.

@aarora79 I don't understand. This is a Claude Code issue. The upstream MCP servers of your MCP Gateway are opaque to Claude. This problem only exists where Claude integrates with an MCP which in your case is your MCP Gateway, I'd assume.

At my work, we have a central MCP Gateway and we had exactly this problem here, but we only had to fix it for the MCP Gateway itself. It's own identifier URI had to have a path. But none of the transitive, upstream MCPs were involved, because Claude doesn't see them, doesn't authenticate/authorize against them directly.

I guess I'm misinterpreting something from your response.

@whiskeysierra so we also have a Gateway but I think there is a difference in topology from yours. From what I understand, your gateway is one MCP endpoint from Claude's view, so one path-qualified identifier URI covers it. Our registry exposes each registered MCP server as its own distinct path (https://gw/<server>/mcp, our Gateway is a reverse proxy), and a coding assistant adds each as a separate MCP connection, each runs its own PRM discovery and sends its own resource. So we have N front-door endpoints, not one, hence N resources. (To your point: this isn't about the transitive upstream MCPs, which Claude never sees or authenticates against; it's the N distinct front-door URLs Claude connects to directly.)

RFC 9728 §3.3 lets a PRM advertise the origin as its resource (connection URL _or_ origin), so once the SDK stops appending the slash, every per-server PRM can advertise the shared origin and we register one origin identifier URI for the whole gateway. Today, because bare-origin is unusable on Entra (the slash), we're forced into one path-qualified URI per server.

Bueller?

Stripping the trailing slash is necessary but not sufficient — a second bug hides behind it.

Hit this on 2.1.258 against a server that hosts two RFC 8707 resources on one origin (RFC 9728 explicitly supports this: "Using path components enables supporting multiple resources per host. This is required in some multi-tenant hosting configurations.").

• Server URL: https://mcp.example.com/mcp
• /.well-known/oauth-protected-resource → "resource": "https://mcp.example.com" (a different API on the same host)
• /.well-known/oauth-protected-resource/mcp → "resource": "https://mcp.example.com/mcp"
• GET/POST /mcp → 401 with WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource/mcp"

Claude Code emits resource=https%3A%2F%2Fmcp.example.com%2F — the origin, plus this issue's trailing slash. A/B against the authorization endpoint, all else identical (same client, same PKCE, same scopes):

| resource sent | Result |
|---|---|
| https://mcp.example.com/ | invalid_target |
| https://mcp.example.com | invalid_target ← the de-slashed value still fails |
| https://mcp.example.com/mcp | 303 → consent ✅ |

So the fix requested here (de-slash) leaves this class broken. The client also needs to take resource from the PRM document that WWW-Authenticate: resource_metadata points at, rather than deriving it from the server URL's origin.

Spec basis: the MCP authorization spec requires clients to parse WWW-Authenticate and respond appropriately to 401s, and says clients SHOULD provide "the most specific URI that they can" — https://mcp.example.com/mcp is listed there as a valid canonical resource URI. This matters for any deployment that deliberately separates the MCP transport's audience from a product API's audience on the same origin, which is a security boundary rather than an exotic setup: collapsing them makes a token minted for an MCP session valid against the full REST API.

Ruled out a stale client cache: removed and re-added the server, and confirmed genuinely fresh state in the debug log (No client info found, a new redirect port, and a fresh discovery with no Returning cached discovery state hit). Identical wrong value.

Also verified the server side is conformant, so this isn't a server misconfiguration: correct 401 challenge on both GET and POST, both PRM documents returning 200 application/json with distinct correct resource values, the AS advertising both in protected_resources, and /mcp/ 307-redirecting to /mcp.

Same class of failure we keep hitting across clients: Inspector/green path looks fine, then a real client mutates the PRM resource (trailing-slash WHATWG normalization) and Entra (or any exact-match AS) rejects with AADSTS9010010 / audience mismatch.

We've been treating this as one cell in a broader client×server compatibility matrix — PRM resource string vs endpoint URL, trailing-slash exact match, DCR vs static client_id, needs-auth discovery — because each shipping client breaks in a different doorway.

If useful while this lands: free CompatLab scorecard / early access (permission-only demand test) https://compatlab-waitlist.vercel.app — happy to compare notes on which clients still rewrite vs preserve the raw resource string.

Same error code, different topology — reporting it here since the trailing-slash fix wouldn't resolve it, and it may be worth handling in the same change.

Setup: the MCP server is protected by Auth0 as the authorization server, with Entra as an upstream enterprise connection (strategy: waad, identity_api: microsoft-identity-platform-v2.0). So Entra authenticates the user, but Auth0 issues the token. That differs from the Business Central case above, where Entra is itself the authorization server.

What happens: Claude Code sends resource to Auth0, Auth0 forwards it to Entra during federation, and Entra rejects with AADSTS9010010.

Authorize URL:

https://<tenant>.auth0.com/authorize
  ?audience=https://api.example.com/core
  &response_type=code
  &client_id=...
  &code_challenge=...&code_challenge_method=S256
  &redirect_uri=http%3A%2F%2Flocalhost%3A8765%2Fcallback
  &resource=https%3A%2F%2Fmcp.example.com%2F

Auth0 log for the failed attempt:

{
  "type": "f",
  "description": "AADSTS9010010: The resource parameter provided in the request doesn't match with the requested scopes",
  "audience": "https://api.example.com/core",
  "scope": "openid profile email offline_access",
  "details": { "qs": { "error": "invalid_target" } }
}

Why the trailing-slash fix doesn't cover this: the scopes here are ordinary OIDC scopes (openid profile email offline_access), not Entra resource-prefixed scopes. There is no scope whose prefix could match resource, with or without the trailing slash — so normalising the slash would leave this failing identically.

Ruled out on the server side: the Auth0 connection has no upstream_params (so the forwarding isn't configurable), and identity_api is v2 — where Microsoft rejects resource alongside v2-style scopes by design. There is no setting that stops Auth0 forwarding it.

What would fix it: omitting resource when the authorization server doesn't implement RFC 8707, or a way to opt out per server. Auth0 ignores the parameter itself but passes it upstream, so sending it to a non-supporting AS is strictly harmful here. Related: modelcontextprotocol/modelcontextprotocol#1614 proposes making it OPTIONAL.

Happy to provide trace IDs or test against a build.

@SammedVJS thanks for the Auth0→Entra federation case — that is a different cell than “Entra is the AS,” and you’re right that a trailing-slash-only fix would leave it failing.

Useful split for anyone else hitting AADSTS9010010:

• Entra-as-AS: resource string mutations (trailing slash / WHATWG normalize) vs exact audience match — slash hygiene can help.
• Auth0-as-AS + Entra upstream (waad / identity_api v2): Auth0 ignores resource but still forwards it; Entra then rejects because scopes are ordinary OIDC (openid profile email offline_access) with no resource-prefixed match. Slash normalize cannot fix that.

Agree the durable client behavior is: omit resource when the authorization server does not implement RFC 8707 (or provide a per-server opt-out). modelcontextprotocol/modelcontextprotocol#1614 making it OPTIONAL is the right direction for this topology.

If maintainers want a minimal repro matrix cell: Auth0 authorize with resource= set + Entra enterprise connection + OIDC-only scopes → expect invalid_target / AADSTS9010010; same flow with resource omitted → should pass federation.

Another cell: Auth0 as the authorization server, honouring resource itself — no Entra anywhere.

Adding this because the Auth0 cases above are all Auth0-as-AS with Entra federated upstream, where the conclusion was that Auth0 ignores resource and merely forwards it. That holds only under Auth0's default resource-parameter profile. A tenant configured to honour RFC 8707 resolves resource itself, by exact string, against its registered resource servers — and then this bug is fatal in the same way it is for Entra-as-AS.

Setup:

• MCP server at https://mcp.example.com/mcp
• /.well-known/oauth-protected-resource advertises "resource": "https://mcp.example.com" — no path, the form the MCP spec's own trailing-slash note prescribes
• An Auth0 resource server registered under exactly that identifier

Claude Code 2.1.270 sends resource=https%3A%2F%2Fmcp.example.com%2F.

Auth0 finds nothing registered under that string and answers 403 at /authorize. The diagnostics are worse than Entra's: no error code reaches the client, the browser shows Auth0's generic "Oops!, something went wrong" page, and nothing on it distinguishes this from a tenant misconfiguration. We isolated it only by replaying /authorize with curl and varying one parameter at a time:

| resource sent | HTTP |
|---|---|
| https://mcp.example.com/ — what Claude Code sends | 403 |
| https://mcp.example.com — what the metadata advertises | passes resource resolution |

Two things that may matter for the fix:

1. It is not an Entra quirk. Any authorization server that matches resource by exact string is affected, and exact-string matching is what RFC 8707 and RFC 9728 §3.3 both assume.
2. The workaround pushes servers away from the recommended spelling. Giving the identifier a path component — https://mcp.example.com/mcp — makes the normalization a no-op, and that is what we shipped. It is unavailable to anyone whose identifier is fixed by something outside their control, and it means declining the form the MCP specification explicitly recommends.

For whoever picks this up: MCP 2026-07-28 states the underlying principle as a MUST NOT, for iss rather than resource — "clients MUST NOT apply scheme or host case folding, default-port elision, trailing-slash, or percent-encoding normalization (RFC 3986 Sections 6.2.2-6.2.3) before comparison." resource is compared the same way, so the same rule wants applying there.

@SammedVJS thanks for the Auth0→Entra federation case — that is a different cell than “Entra is the AS,” and you’re right that a trailing-slash-only fix would leave it failing. Useful split for anyone else hitting AADSTS9010010: Entra-as-AS: resource string mutations (trailing slash / WHATWG normalize) vs exact audience match — slash hygiene can help. Auth0-as-AS + Entra upstream (waad / identity_api v2): Auth0 ignores resource but still forwards it; Entra then rejects because scopes are ordinary OIDC (openid profile email offline_access) with no resource-prefixed match. Slash normalize cannot fix that. Agree the durable client behavior is: omit resource when the authorization server does not implement RFC 8707 (or provide a per-server opt-out). modelcontextprotocol/modelcontextprotocol#1614 making it OPTIONAL is the right direction for this topology. If maintainers want a minimal repro matrix cell: Auth0 authorize with resource= set + Entra enterprise connection + OIDC-only scopes → expect invalid_target / AADSTS9010010; same flow with resource omitted → should pass federation.

@slowe89 Thanks for the response.

Ran the repro you asked for. Confirmed: omitting resource passes federation, everything else identical.

Auth0 as AS, Entra enterprise connection (strategy: waad, identity_api: microsoft-identity-platform-v2.0), OIDC-only scopes.

A — with resource:

/authorize?audience=https://api.example.com/core&response_type=code&client_id=...
  &code_challenge=...&code_challenge_method=S256
  &redirect_uri=http://localhost:8765/callback
  &scope=openid+profile+email+offline_access&state=...
  &resource=https%3A%2F%2Fmcp.example.com%2F

→ error=access_denied&error_description=AADSTS9010010: The resource parameter provided in the request doesn't match with the requested scopes

B — byte-identical minus resource: → redirects to the callback with ?code=.... Federation succeeds.

Same client_id, same scope, same audience, same connection, same PKCE challenge. The only difference is the parameter.

One gotcha for anyone reproducing: run B in a private window. Auth0's session cookie replayed the failed transaction on my first attempt and made B look like it failed too.

This supports omitting resource when the authorization server does not implement RFC 8707 (Auth0 ignores it locally but still forwards it upstream), or a per-server opt-out. modelcontextprotocol/modelcontextprotocol#1614.

@johakoch thanks — that third cell is important. Auth0-as-AS honouring RFC 8707 locally (exact-match on resource, no Entra) is a different failure mode from Auth0+Entra federation where Auth0 ignores resource but forwards it.

Updated matrix for anyone hitting this:

1. Entra-as-AS — slash/exact match on resource vs scope/audience prefix (trailing-slash / WHATWG normalize breaks it; slash hygiene helps).
2. Auth0-as-AS + Entra upstream — Auth0 ignores resource locally but forwards it; Entra rejects OIDC-only scopes → AADSTS9010010. Slash hygiene does not help; omit resource (or per-server opt-out) does.
3. Auth0-as-AS honouring resource (exact-match, no Entra) — same class as (1): metadata advertises unslashed host-root, client sends slashed → Auth0 403 / opaque Oops page. Slash hygiene matters again.

@SammedVJS thanks for running the omit-resource repro — confirmed: with resource → AADSTS9010010; without → federation succeeds. For anyone else reproducing: use a private window on the omit-resource pass; Auth0 session cookie can replay the failed transaction and make a clean B look broken.

Confirming this still reproduces on Claude Code v2.1.282 against Microsoft's ADO MCP.

The upstream fix modelcontextprotocol/typescript-sdk#2581 shipped in @modelcontextprotocol/client@2.1.0 on 2026-09-23.

Config:

"ADO Management Tool": {
    "type": "http",
    "url": "https://mcp.dev.azure.com/<org>",
    "oauth": {
        "clientId": "<redacted>",
        "authServerMetadataUrl": "https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration"
    }
}

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

Claude Code is still sending resource=<origin>/ with the trailing slash, per this issue's original root cause. Waiting on an SDK dependency bump in Claude Code to pull in typescript-sdk 2.1.0.

+1 — also reproduces with an AWS Bedrock AgentCore Gateway MCP server, where the downstream authorization server is Auth0 rather than Entra ID directly. Auth0 is configured with an Enterprise (Azure AD) connection, so Entra enters the picture one hop removed: Auth0 federates the login to Entra, and that's where AADSTS9010010 surfaces.

One data point that might be useful: in our case the advertised MCP resource URL already includes a path segment (not a bare origin), so the trailing-slash-normalization root cause described above may not be the only trigger — worth checking whether the fix also covers resource values that already have a path but still mismatch once relayed through a federated IdP hop.

Confirmed on the latest Claude Desktop build as of 2026-10-14 — still reproduces.