AADSTS9010010: Resource parameter doesn't match the requested scopes (fix)

What does AADSTS9010010 mean?

Microsoft’s error code reference doesn’t list AADSTS9010010 (checked 30 October 2026).

My lab tenant returned this message for a client-credentials token request that carried both scope=https://graph.microsoft.com/.default and resource=https://management.azure.com/:

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

Microsoft does explain the code, on its page about securing an MCP server with Entra ID:

AADSTS9010010 means the Application ID URI configured on your app registration doesn’t exactly match the value of the resource parameter in the client’s OAuth request.

The same page gives a second cause: “This error also occurs when the client sends a scope that’s defined on a different app registration than the one referenced by the resource parameter. Microsoft Entra ID resolves the resource and the scope to the same resource app; if they point at different app registrations, the request fails.” That second cause is what the lab request did: the scope names Microsoft Graph, the resource names Azure Resource Manager.

Background. On the v2.0 endpoint the resource is normally named inside the scope. Microsoft’s scopes page: “Using scope={resource-identifier}/.default is functionally the same as resource={resource-identifier} on the v1.0 endpoint.” The resource parameter comes back through RFC 8707 (Resource Indicators), which the MCP authorization spec requires. Microsoft’s MCP page: “The MCP specification requires the client to identify the protected resource it wants a token for by sending the resource parameter (from RFC 8707) in its token request.” So a request now carries the resource twice, and the two must agree.

The match is exact. Microsoft: “The resource value the client sends must match the Application ID URI character for character, including the scheme (https://), casing of the host, and path. A trailing slash is a common culprit: because an Application ID URI can’t end with a slash, a client that sends resource=https://mcp.contoso.com/ never matches the registered https://mcp.contoso.com.”

Reproduced in the lab

On 30 October 2026 an automated lab run sent a client-credentials request to the token endpoint with scope=https://graph.microsoft.com/.default and resource=https://management.azure.com/. Entra returned AADSTS9010010 with this first line:

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

That confirms the code and its wording at the token endpoint for an app (not a user) request. It lands in AADServicePrincipalSignInLogs for an app-only request: one row, Failure, client credential type “federatedIdentityCredential”, resource Microsoft Graph. The KQL below was run on these rows (how). Both queries found the row (the second with its app ID placeholder replaced).

Is it an attack?

No. It is a mismatch in how the client builds its token request. No token is issued.

Pattern	Likely meaning
An MCP client (Claude Code, an IDE, an agent) fails to connect to an Entra-protected MCP server	The client sends resource with a trailing slash, or a URL that differs from the Application ID URI. Users report exactly this in claude-code issue 52871, where resource=https://mcp.businesscentral.dynamics.com/ was sent while the server’s metadata declared it without the slash.
A script or daemon sends resource and scope for two different APIs	The scope belongs to another app registration, as in the lab request.
A broker or identity provider in front of Entra forwards resource with only OIDC scopes (openid profile)	Users report this with Auth0 federated to Entra in the same GitHub issue. Our reading: no resource-prefixed scope exists to match.
Your own MCP server app is still on v1 access tokens	Microsoft: if requestedAccessTokenVersion isn’t 2, “you can’t register an HTTPS Application ID URI that matches your MCP server URL, so the resource value can never match.”

Our reading: the request fails before a token is issued, and only the app’s own owner can make it match. There is nothing an attacker gains from triggering it.

How do I find it in my logs (KQL)?

Microsoft doesn’t document which sign-in table 9010010 is logged in. Our reading: user-delegated requests (MCP clients signing in a user) would land in SigninLogs or AADNonInteractiveUserSignInLogs, and app-only requests like the lab one in AADServicePrincipalSignInLogs. That is not verified. Check all three:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "9010010"
| summarize Rows = count(), LastSeen = max(TimeGenerated) by SourceTable, AppId, ResourceDisplayName
| sort by Rows desc

To fix the request you need the right resource. For an app that fails with 9010010, see which resources it does get tokens for:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where AppId == "<app id of the failing client>"
| summarize Successes = countif(ResultType == "0"), Failures9010010 = countif(ResultType == "9010010") by SourceTable, ResourceDisplayName, ResourceIdentity
| sort by Failures9010010 desc

A resource with failures and no successes is the one whose resource value or scope is wrong. Both queries are starting points; adjust the time window to your retention.

How do I fix AADSTS9010010?

For the user: you can’t fix this yourself. Report the app or MCP server name to whoever set it up, and include the full error.

For developers (client side):

1. If you talk to the v2.0 endpoint and don’t need RFC 8707, drop resource and name the API only in scope, for example scope=https://graph.microsoft.com/.default. Microsoft’s scopes page says the two are functionally the same.
2. If you must send resource (MCP clients do), send it verbatim from the server’s protected resource metadata. Don’t normalise it; the reporter of claude-code issue 52871 suspects that round-tripping it through a URL parser added the trailing slash. Nobody in the thread confirmed that.
3. Make every scope in the request belong to the same API as resource. Remove scopes from other APIs and request them in a separate token request.

For developers (MCP server side), from Microsoft’s MCP page:

1. Set the app registration to v2 access tokens (requestedAccessTokenVersion = 2).
2. Set the Application ID URI to the exact canonical URL of your MCP server, with no trailing slash.
3. Publish that same value as resource in your protected resource metadata, so clients send what Entra expects.

For admins: compare the failing app’s resource value with the Application ID URI of the API’s app registration. If they differ by a slash, a case or a path, that is the cause.