Share via

Microsoft Graph returns empty @microsoft.graph.downloadUrl for OneDrive files in app-only context

peted 0 Reputation points
2026-04-28T02:37:30.4833333+00:00

Summary Our application uses Microsoft Graph with app-only authentication (client credentials flow) to read files from OneDrive. Listing files works correctly. However, when we request a download URL for individual files, Graph returns a 200 response with file metadata present but the @microsoft.graph.downloadUrl field is missing or empty. The same files download successfully via the OneDrive web UI when accessed by tenant users. This started occurring on or around April 24, 2026. Environment

Tenant: M365 Business (resold via GoDaddy) Tenant ID: App registration ID: Application: Google Apps Script backend calling Graph via HTTPS Authentication: client credentials flow (app-only, no user context)

API permissions configured

Files.ReadWrite.All (Application) — admin consent granted, status: Granted for tenant Mail.Send (Application) — admin consent granted (used for separate email feature) User.Read (Delegated) — granted (not relevant to this issue)

Verified in the Azure portal on April 27, 2026. All Application-type permissions show as fully consented. Symptom — exact API behavior Endpoint A: GET /drives/{driveId}/items/{itemId}?$select=id,name,@microsoft.graph.downloadUrl

Response: 200 OK id and name returned correctly @microsoft.graph.downloadUrl field is missing from the response or returned as empty

Endpoint B: GET /drives/{driveId}/items/{itemId}/content?$format=value

Expected: 302 redirect with Location header containing pre-signed download URL Actual: no Location header in response

What we have ruled out

Token freshness is not the cause. We disabled token caching in our application and forced a fresh token to be minted from Azure AD on every Graph call. Behavior was identical — the empty @microsoft.graph.downloadUrl field was returned regardless of token age. Permissions are correct. Files.ReadWrite.All (Application) is granted with admin consent. Verified in the Azure portal. Files are not corrupted. Identical files download successfully via the OneDrive web UI for tenant users. File metadata is intact. ID, name, parent folder, and other fields return correctly. Only the download URL field is missing. Affects multiple applications using the same auth path. Our file management feature and our PDF annotation review feature both exhibit identical behavior. Both use app-only Graph authentication against the same tenant.

Diagnostic data captured Test run from Microsoft Graph Explorer on April 27, 2026, against the same tenant and a file ID known to fail in our app-only flow:

Query: GET /drives/{driveId}/items/{itemId}?$select=id,name,file,folder,size,webUrl Auth context: delegated user — signed in as a tenant admin account with Files.Read.All consented Response: 403 accessDenied request-id: client-request-id: timestamp: 2026-04-28T03:26:19 UTC

The combined picture: app-only context returns 200 OK with empty downloadUrl. Delegated user context (different user than the drive owner) returns 403 accessDenied for the same item. The OneDrive web UI works fine for the actual drive owner. This is consistent with auth-context-dependent behavior at the SharePoint/OneDrive layer rather than a Graph token or app-permission issue. What we suspect The pattern — 200 response with metadata present, download URL field selectively suppressed for app-only callers, OneDrive web UI unaffected — suggests a tenant-side configuration is suppressing the field for app-only Graph calls. Two specific tenant configurations have been suggested as candidates that match this symptom pattern:

SharePoint "Unmanaged Devices" access policy (SharePoint Admin Center → Policies → Access Control → Unmanaged Devices). If set to "Allow limited, web-only access" via Set-SPOTenant -ConditionalAccessPolicy AllowLimitedAccess, SharePoint reportedly strips pre-authenticated download URLs for app-only callers because they lack managed device context, while continuing to return metadata. Conditional Access "Use app enforced restrictions" session control targeting SharePoint Online. App-only service principals have no device state to evaluate against this policy, which would cause SharePoint to silently downgrade the response.

Other possibilities: DLP rules suppressing redistributable URLs, or sensitivity label policies blocking download-URL generation for labeled content. Because this tenant is resold through GoDaddy, we do not have direct access to the Microsoft 365 admin center, SharePoint Admin Center, or tenant PowerShell. GoDaddy support (case #164823981) confirmed they cannot investigate Graph API behavior and directed us to contact Microsoft directly. Questions for the community

Has anyone observed Graph selectively suppressing @microsoft.graph.downloadUrl for app-only tokens while still returning other file metadata? Are there documented tenant-level configurations (Conditional Access, DLP, sensitivity labels, SharePoint Unmanaged Devices policy, or otherwise) that suppress this field for app-only callers? Was there any change to Microsoft Graph behavior or default tenant configurations on or around April 24, 2026 that could explain this? For tenants that don't have direct admin center access (resold tenants), what is the recommended escalation path for Graph API behavior questions?

Thank you for any insight.

Microsoft 365 and Office | Development | Other
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Steven-N 25,305 Reputation points Microsoft External Staff Moderator
    2026-04-28T05:19:48.9466667+00:00

    Please note that Q&A forum is a public platform, and moderators will modify the question to hide personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

    Hi peted

    I have conducted some research and to directly answer your questions:

    1/Has anyone observed Graph selectively suppressing @microsoft.graph.downloadUrl for app-only tokens while still returning other file metadata?

    Yes, this is a known pattern. The @microsoft.graph.downloadUrl field is not standard metadata, it's a pre-authenticated, short-lived URL that Graph generates on-demand and evaluates separately from fields like id or name. It requires no Authorization header when accessed directly, meaning the service must actively grant it like a capability. Tenant-side enforcement layers can suppress it before Graph emits the field, even when Files.ReadWrite.All is fully consented.

    Link reference: https://learn.microsoft.com/en-us/graph/api/driveitem-get-content?view=graph-rest-1.0&tabs=http

    2/Are there documented tenant-level configurations that suppress this field for app-only callers?

    You can read here for more information:

    Sensitivity labels with encryption: Files uploaded with a sensitivity label that applies encryption cannot have their content processed by SharePoint, disabling features like eDiscovery, DLP, and search. Download URL generation falls into the same category. An app-only caller without decryption rights may receive no URL field at all rather than an error. As states in this LINK.

    MarkNewFilesSensitiveByDefault: Technically, SharePoint can be configured to treat all files as sensitive until DLP scanning completes, blocking access until then. App-only callers can be treated as external in this context. If Set-SPOTenant -MarkNewFilesSensitiveByDefault BlockExternalSharing was toggled around April 24, it matches the symptom exactly metadata accessible, download URL suppressed.

    Conditional Access on service principals. Entra ID CA policies can now target service principals. If one was applied to your app registration restricting download-capable access, Graph can suppress the URL silently. Check the Entra sign-in logs under "Service principal sign-ins" for CA policy outcomes.

    3/ Was there any change to Microsoft Graph or default tenant configurations around April 24, 2026?

    Based on my research, nothing confirmed from public documentation at that date. You can check this via Microsoft 365 Message Center and the Microsoft 365 Service Health Dashboard.

    4/ For resold tenants without direct admin center access, what is the recommended escalation path?

    In this context, you can create the Azure support ticket via Azure Portal

    How to open a support ticket:

    1. Go to the Azure Portal.
    2. Select Create a support request.

    Thank you for your patience, and I hope the support team can get this unblocked for you quickly.

    I hope this helps.

    Note: Please follow the steps in [our documentation] to enable email notifications if you want to receive the notification for this thread.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.