Microsoft Graph /content returns non-preauthenticated SharePoint URL which results in 401

Question

Microsoft Graph /content returns non-preauthenticated SharePoint URL which results in 401

Xu, Fanqing (AZSA) 0

I'm seeing behavior that appears inconsistent with the Microsoft Graph documentation for downloading driveItem content.

Expected behavior

According to the documentation, calling:

GET /drives/{drive-id}/items/{item-id}/content

should return a 302 Found redirect to a preauthenticated download URL, equivalent to @microsoft.graph.downloadUrl, which can be downloaded without additional authentication.

Observed behavior

Retrieve driveItem metadata:

GET /drives/{drive-id}/items/{item-id}

Response contains:

"@microsoft.graph.downloadUrl": "https://<tenant>.sharepoint.com/sites/<site>/_layouts/15/download.aspx?UniqueId=<guid>&Translate=false&ApiVersion=2.0"

Download content:

GET /drives/{drive-id}/items/{item-id}/content

Response:

302 Found
Location:
https://<tenant>.sharepoint.com/sites/<site>/_layouts/15/download.aspx?UniqueId=<guid>&Translate=false&ApiVersion=2.0

Access the returned URL:

401 Unauthorized

The URL from @microsoft.graph.downloadUrl and the Location header are identical, but the URL is not directly downloadable and requires authentication.

Questions

Is this behavior expected?
Has the behavior of @microsoft.graph.downloadUrl or /content recently changed? (The failure starting mid-Sep.)
Does Microsoft Graph still guarantee that @microsoft.graph.downloadUrl is a preauthenticated download URL?
If preauthenticated download URLs are being deprecated, what is the recommended replacement for daemon/background applications downloading files from SharePoint Online?

Additional notes

File metadata retrieval succeeds.
/content returns 302 successfully.
Only the final download URL returns 401.
SharePoint tenant administrators confirmed no recent SharePoint configuration changes.
We were informed that the historical tempauth mechanism may be deprecated, but it is unclear whether that is related to this behavior.

Any clarification would be appreciated.

0 comments

1 answer

Your answer

Answer 1

Yes. The documented contract still says /content returns 302 Found to a preauthenticated download URL, and that this is the same URL exposed as @microsoft.graph.downloadUrl. The documentation also states that the download URL does not require an Authorization header and is short-lived.

Supported facts from the documentation:

GET /drives/{drive-id}/items/{item-id}/content returns 302 Found.
The Location header points to a preauthenticated download URL.
That URL is the same value exposed by @microsoft.graph.downloadUrl.
@microsoft.graph.downloadUrl is defined as a URL that can be used to download file content without authentication.
The URL is temporary and should be used immediately because it can expire within minutes; the driveItem resource page also states it is short-lived and cannot be cached.

For the observed 401 Unauthorized on the final SharePoint URL:

That behavior does not match the documented expectation for @microsoft.graph.downloadUrl.
The provided material does not state that @microsoft.graph.downloadUrl has been deprecated.
The provided material does not state that preauthenticated download URLs have been replaced for daemon or background download scenarios.

What the available material does show is that Microsoft still documents @microsoft.graph.downloadUrl as the intended mechanism in cases where the redirected /content URL must be consumed directly, including JavaScript/CORS scenarios.

There is one related limitation in the available material: behavior at the storage backend can vary in some scenarios when using the direct download URL. A Microsoft Q&A answer for range downloads states that direct use of @microsoft.graph.downloadUrl bypasses Graph and interacts directly with the file storage backend, and backend behavior may vary by scenario. That supports treating a 401 at the final URL as a service/backend behavior issue rather than as evidence of a documented contract change.

Based on the available material, the direct answers are:

Is this behavior expected?
No, not according to the documented behavior for /content and @microsoft.graph.downloadUrl.
Has the behavior recently changed?
No documented change is present in the available material.
Does Microsoft Graph still guarantee that @microsoft.graph.downloadUrl is a preauthenticated download URL?
Yes, that is still how it is documented.
If preauthenticated download URLs are being deprecated, what is the replacement?
No deprecation or replacement is stated in the available material.

References: