Graph /me/drive/root/search returns 403 accessDenied while /me/drive/root/children returns 200 with same delegated Files.Read.All + Sites.Read.All token

Question

Summary

Delegated Microsoft Graph token can list OneDrive children but drive search fails with HTTP 403 accessDenied for the same user/token/app. A second app registration in the same tenant can search successfully with the same scopes.

Environment

• Authority: https://login.microsoftonline.com/common
• Flow: OAuth2 authorization code + refresh (offline_access)
• Token type: delegated (not app-only)
• Scopes requested/granted (confirmed in token scp and vault response):
  • Files.Read.All
  • Sites.Read.All
  • User.Read
  • plus openid profile email
• Audience (aud): 00000003-0000-0000-c000-000000000000 (Microsoft Graph)
• Failing app (production): [Moderator note: Personally Identifiable Information removed]
• Working app (staging, same tenant / same scopes, search succeeds): c181e7ad-… (can provide full ID if needed)

Repro

Same access token:

1. GET https://graph.microsoft.com/v1.0/me → 200
2. GET https://graph.microsoft.com/v1.0/me/drive/root/children?$top=1 → 200
3. GET https://graph.microsoft.com/v1.0/me/drive/root/search(q='xlsx') → 403

Error body (sanitized):

{

  "error": {

    "code": "accessDenied",

    "message": "Access denied"

  }

}

Answer 1

Dear Andrew,

Good day, and thank you for the exceptionally detailed report.

As a forum moderator, I genuinely wish I could inspect your app registrations and tenant configuration to identify the difference directly. Unfortunately, my role here is limited to providing general guidance and pointing you toward the right escalation path. From my research, since /children succeeds, /search fails only for the production app, and a second app registration in the same tenant can search the same user's drive successfully, this does not appear to be a normal missing-scope, OneDrive provisioning, or user-permission issue.

I am also not aware of any documented Entra or SharePoint setting that would intentionally permit GET /me/drive/root/children while denying GET /me/drive/root/search(q='xlsx') for a delegated token containing both Files.Read.All and Sites.Read.All. Microsoft documents Files.Read as the least-privileged delegated permission for driveItem: search, with Files.Read.All and Sites.Read.All listed as sufficient higher-privileged alternatives. Your production token therefore satisfies the documented permission requirement.

Given that, the behavior seems more consistent with one of the following:

1. An app-specific SharePoint or Search authorization state, or a backend policy applied to that app ID.
2. Stale service-principal consent or provisioning metadata on the production app.
3. A Conditional Access or app-control difference between the two enterprise applications.
4. A service-side defect affecting the production app ID specifically.
5. A difference in the actual token context beyond scp, such as tenant, user, client app, claims challenge, or authentication context.

A few things worth comparing between the two app registrations:

Since both apps exist in the same tenant with the same scopes, it may be worth checking whether any of the following differ:

• The Enterprise Application properties for each app (assignment requirements, visibility, and user assignment settings).
• Any Conditional Access policies scoped to specific cloud apps, which could target one app ID but not the other.
• The service principal consent state, in case the production app's grant is stale despite the token showing the correct scopes.
• Whether either app has a claims mapping policy or authentication context applied.
• The app creation date, in case the production app predates a change in how search authorization is evaluated.

Escalation without an Azure technical support plan:

You do not need to rely solely on an Azure technical support plan. If you have a Microsoft 365 tenant, a Global Admin can open a service request through the Microsoft 365 Admin Center instead, and Graph API issues can be routed appropriately from there. When submitting, I would recommend including everything you have already documented here, particularly:

• Both app IDs (working and failing).
• The Graph request IDs from the failed calls.
• The exact repro steps showing /children succeeding and /search failing with the same token.
• Confirmation of the scp claim contents.

That level of detail should help the engineer route it to the Graph or SharePoint Search team quickly rather than starting from generic permission troubleshooting. For detailed instructions on how to get support, please refer to Get support - Microsoft 365 admin. For additional assistance, use this link to find the appropriate contact number from your region: Global Customer Service phone numbers - Microsoft Support 

I truly hope you get your issue resolved swiftly. Please know that even though I can't directly intervene, directing you to the correct, specialized support is the most effective help I can provide from my position. Thank you for your patience and understanding. I'm looking forward to your reply.  

---

If the answer is helpful, please click "Yes" and kindly upvote it. If you have extra questions about this answer, please click "Comment".  

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.