[FEATURE] MCP OAuth: allow overriding or omitting RFC 8707 `resource` (Entra ID AADSTS9010010) in Claude Code, Claude Desktop, and claude.ai
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Claude's built-in MCP OAuth sign-in (Claude Code, Claude Desktop, and claude.ai) can't complete a sign-in against Microsoft Entra ID for any MCP server that correctly implements the MCP authorization spec. The server itself isn't misconfigured. The failure comes from a conflict between how the MCP spec uses RFC 8707 and RFC 9728 and how Entra interprets the resource parameter.
What the MCP spec requires:
The MCP authorization spec requires the client to send two parameters to the authorization server:
scope names the permissions being requested, for example api://<client-id>/session:role:ANALYST_MCP_ROLE.
resource (RFC 8707, Resource Indicators) names the target server. Its value is the MCP server URL that the resource server advertises in its protected resource metadata (RFC 9728).
RFC 9728 also requires the advertised resource to be the server's own identifier, the URL the client used to discover the metadata, and the client must reject metadata where they don't match. So a compliant resource server can't advertise anything other than its own URL. It can't advertise an Entra App ID URI such as api://<client-id>
What Entra does:
Entra's v2 endpoint identifies the target API from the scope, not from resource. Since around March 2026, Entra also rejects any request where resource doesn't byte-match the App ID URI of the API that owns the requested scopes:
invalid_target: AADSTS9010010: The resource parameter provided in the request
doesn't match with the requested scopes.
The MCP server URL can never equal the App ID URI. App ID URIs are typically api://<client-id>, and Entra only accepts https:// App ID URIs on domains the tenant has verified, which excludes a vendor's hostname such as <account>.snowflakecomputing.com.
Verified against a Snowflake managed MCP server (External OAuth with Entra ID)
Snowflake's protected resource metadata (RFC 9728) advertises:
json
"resource": "https://<account>.snowflakecomputing.com/api/v2/databases/<db>/schemas/<schema>/mcp-servers/<name>"
Probing Entra's v2 /authorize endpoint directly (validation happens before sign-in) with the same client, tenant and redirect URI, changing only scope and resource:
scope | resource | Result
-- | -- | --
api://<client-id>/session:role:<ROLE> | Snowflake MCP server URL (from metadata) | ❌ AADSTS9010010
session:role:<ROLE> (bare) | Snowflake MCP server URL (from metadata) | ❌ AADSTS9010010
api://<client-id>/session:role:<ROLE> | api://<client-id> | ✅ accepted (sign-in page)
api://<client-id>/session:role:<ROLE> | (omitted) | ✅ accepted (sign-in page)
The resource value alone determines the outcome. The value a spec-compliant client must send (the advertised server URL) is the one Entra rejects.
Who this affects:
This affects any resource server that correctly publishes RFC 9728 metadata and uses Entra as its authorization server, including:
Snowflake managed MCP servers (https://<account>.snowflakecomputing.com/api/v2/databases/<db>/schemas/<schema>/mcp-servers/<name>) with Entra as the External OAuth provider.
AWS Bedrock AgentCore Gateway (https://<id>.gateway.bedrock-agentcore.<region>.amazonaws.com/mcp).
Custom MCP servers on Azure App Service (*.azurewebsites.net).
Microsoft's own remote MCP servers (Azure DevOps, Business Central).
Even if Entra resolved the target API from resource instead of scope, the request would still fail. Entra only resolves App ID URIs or verified-domain URIs, and a vendor-hosted MCP server URL can be neither. A client-side override is the only fix that doesn't depend on Microsoft redesigning its resource model.
Proposed Solution
One capability across all Claude clients: let users or admins override, or omit, the RFC 8707 resource parameter in MCP OAuth requests. No Claude client supports this today. Claude Code's .mcp.json oauth block already supports overriding the client ID, scopes and authorization server, so it only needs the new resource field. Claude Desktop and claude.ai custom connectors support none of these overrides beyond client ID and secret, so they need the authorization server and scopes overrides as well, or Entra can't be reached at all.
Claude Code
Add oauth.resource to .mcp.json. It takes a string to override the value from protected resource metadata, or false to omit the parameter, mirroring how oauth.scopes overrides scopes_supported:
{
"mcpServers": {
"snowflake-entra": {
"type": "http",
"url": "https://<account>.snowflakecomputing.com/api/v2/databases/<db>/schemas/<schema>/mcp-servers/<name>",
"oauth": {
"clientId": "<entra-client-id>",
"scopes": "api://<entra-client-id>/session:role:<ROLE> offline_access",
"authServerMetadataUrl": "https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration",
"resource": "api://<entra-client-id>" // new: override, or false to omit
}
}
}
}
Either capability unblocks Entra:
Override: send the configured value instead of the metadata value (resource=api://<app> passes validation).
Omit: resource: false (or similar) suppresses the parameter entirely — Entra accepts plain v2 scope-only requests.
Related issues
- https://github.com/anthropics/claude-code/issues/73460: original request for an
oauth.resourceoverride (auto-closed for inactivity, 6 👍) - #76096: same Entra AADSTS9010010 failure, framed as a conflict with the RFC 9728 canonical-resource check (closed)
- #52871: trailing-slash normalization of
resourcebreaking Entra (fixable by exact matching; this case is not) - #26675: pre-configured OAuth client credentials (the
oauthblock this extends) - aws-samples/anthropic-on-aws#254: resource-stripping OAuth proxy built as a workaround for Entra + AgentCore
- kirodotdev/Kiro#10437: same feature requested for another MCP client
Environment
- Claude Code: 2.1.281
- OS: <e.g. macOS 15, Apple Silicon>
- MCP server: Snowflake managed MCP server (streamable HTTP)
- Authorization server: Microsoft Entra ID v2 (
login.microsoftonline.com), via Snowflake External OAuth - Same server works with Snowflake OAuth; fails only when authenticating through Entra
- Probe tests run 10/01/2026
Alternative Solutions
_No response_
Priority
High - Significant impact on productivity
Feature Category
CLI commands and flags
Use Case Example
_No response_
Additional Context
_No response_
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗