senn-techsenn-tech
Infrastructure
Infrastructure2026-10-11· By Franz Senn

OneDrive and SharePoint URLs lose their embedded token on 1 April 2027

On 8 October 2026 the Microsoft 365 Developer Blog announced the retirement of pre-authenticated URLs in SharePoint Online and OneDrive. Page metadata puts publication at 13:10 UTC and names the SharePoint team as author. The next day the Message Center sent MC1492958 to every tenant administrator, classified there as a major change and a retirement, with an action date of 1 April 2027. In one sentence: from that date, no URL handed out by the affected Microsoft Graph file APIs carries an embedded token any more, and the HTTP redirect to such an address goes away too.

What actually disappears

SharePoint has been writing a short-lived token for one specific object straight into the URL, normally as a tempauth query parameter. An HTTP client could fetch that address with no Authorization header at all. That is what ends. The developer blog states the rule broadly: every URL that previously worked without authentication now needs a valid Microsoft Entra ID access token in the header when it is called. For requests that today answer 302 with a pre-authenticated address, Microsoft adds that the API will return the content directly instead.

The API reference says nothing about it yet. The v1.0 page for driveItem: Download content still documents the 302 redirect to a pre-authenticated download URL and states in plain words that calling the download URL needs no Authorization header (checked on 11 October 2026, where the page carries a last-updated stamp of 27 August 2025). Anyone who reads only the API reference will not notice the change coming.

The two migration paths

Path one is a SharePoint token. Microsoft is shipping an OAuth flow for the SharePoint Online resource for every affected API family, and the tenant administrator has nothing to switch on. The token goes on each request to a SharePoint URL, including every single chunk of an upload. This is the universal route and the only one that is documented end to end today.

Path two is Microsoft Graph URLs. Some of the APIs have a direct Graph counterpart, driveItem/contentStream for downloads being the example. For those, Microsoft is introducing a tenant setting that hands a configured client a Graph URL instead of a SharePoint URL, so the client can spend the Graph token it already holds. Note that the blog's own worked example is the upload session and shows path one, a SharePoint token in front of every chunk: for the upload URL there is no Graph counterpart.

Rules from the cmdlet documentation that decide the details:

  1. An empty app list in the setting means all apps. The special value "Empty" stands for requests with no app context at all, such as a browser.
  2. The setting applies to third-party applications only.
  3. Order of precedence is Deny, then Allow, then IsDisabled. A refusal beats an allowance for the same application.
  4. APIs without a Graph counterpart keep returning a pre-authenticated SharePoint URL until the retirement removes the token.
  5. Requests that never go through Microsoft Graph are unaffected. Calling the SharePoint REST API directly is outside the reach of the tenant setting.

The documentation gap, measured

The timeline in the developer blog claims the opt-in setting for Graph URLs is available today. The heading of the very same section about path two reads (Coming in future Microsoft SharePoint Online PowerShell versions), and MC1492958 says the tenant controls arrive in a future release of the SharePoint Online PowerShell.

Measured on 11 October 2026: the Set-SPOTenantPreAuthSettings page does not have those parameters. It documents IsDisabled, Type, Add, Remove, Id, IncludedApps, ExcludedApps, IncludedFeatures and ExcludedFeatures, and nothing else; its feature list counts eleven entries from DataFormWebpart to Whiteboard, none of them about Graph URLs. The anchor -UseGraphUrlIsEnabled that the developer blog links to does not exist on that page. The Get-SPOTenantPreAuthSettings page, on the other hand, already documents the UseGraphUrlSettings parameter set. The mapping of which families have a Graph counterpart is missing from the Set documentation as well.

The change belongs to the SharePoint Online PowerShell module, and those pages come from a public documentation repository. Two things are worth a few minutes there: whether Set-SPOTenantPreAuthSettings.md has gained the UseGraphUrl parameters, and whether the cmdlet reference contains the mapping table. Neither was the case on 11 October 2026. A test run against the switched-on setting is therefore impossible right now, in a test tenant or anywhere else. The read side is documented, the write side is not. Anyone who wants to probe anyway starts with Get-SPOTenantPreAuthSettings -UseGraphUrlSettings and sees what the tenant returns.

Dates and rollout

Deadlines for the pre-authenticated URLs8 / 9 Oct 2026Dev blog and MC149295811 Oct 2026Read documented, writemissing1 April 2027no tempauth URL, no 302Late April 2027rollout expected, per MC
Own diagram after the developer blog and MC1492958. The second step is measured against the two cmdlet pages on 11 October 2026. Step four is the Message Center expectation (completion in late April 2027), a date the product documentation does not name. (source: Microsoft 365 Developer Blog (8 Oct 2026) and MC1492958 (9 Oct 2026))

The Message Center describes a rollout starting in early April 2027 and expected to finish in late April 2027, for Worldwide, GCC, GCC High and DoD. The product documentation itself names only 1 April 2027 as the start of the behaviour change. Anyone scheduling a maintenance window should budget the extra fortnight.

Seven families, six families, four links

MC1492958 lists seven families: file download and content, createUploadSession, copy together with long-running operations and their monitors, preview, thumbnails, versions, and format conversion. The migration step in the developer blog talks about "the six API families listed above", while the "Does this affect you?" section links four calls. Neither document explains the different counting. The difference changes nothing in practice: calling any of the seven families means being affected, and the audit list below applies to all of them.

A typical affected URL looks like this, documented by Microsoft itself:

https://<tenant>.sharepoint.com/sites/samplesite/_layouts/15/download.aspx?UniqueId=<id>&tempauth=v1.ey...

Auditing your own estate

  1. Code that reads tempauth=, access_token=, uploadUrl, getUrl or @microsoft.graph.downloadUrl from a Graph response and then fetches that address without an Authorization header.
  2. HTTP clients with redirect following disabled, or code that inspects the Location header itself. After the deadline, the answer may arrive directly.
  3. Any long-lived stored URL in tables, queues, reports or hand-offs to a browser. Short lifetime was already its weakness; from April 2027 it is useless.
  4. Range downloads. The documentation recommends putting the Range header on the actual download URL today. From April 2027 that header belongs on the Graph URL, and the call needs the token.
  5. Binary downloads that start a file downloader or uploader after resolving a 302.

Measured in our M365 backup console

We run our own M365 backup console for the Senn group on the backup server pbs3, built as a fork of a commercial M365 backup product whose upstream repository is public on GitHub. The image that runs is m365-console:1.3.2-cbpx, up since 7 October. I read the code inside the running container rather than the upstream changelog.

Which families we call

The engine calls three of the seven families: download through @microsoft.graph.downloadUrl and through /content, uploads during a restore through createUploadSession, and file versions through /versions/{version-id}/content. The search patterns preview, thumbnails, /copy, operations/ and format= return zero hits inside our own engine tree. The delta call selects @microsoft.graph.downloadUrl for every item and passes the address down the pipeline.

A URL with a token never reaches our disk. A search across /store/m365/data (6.2 MB, as of 11 October 2026) finds no tempauth in any file. The console has treated the address as short-lived for a while, because it had to: a 46 GiB object once died in our own tenant with HTTP 401 at 32.8 GiB, and on the retry at 22.7 GiB, roughly 65 minutes of transfer each time. Since then the address is re-fetched at least every two minutes and replaced immediately on any 401, up to three times per chunk, against five network attempts per chunk.

Download: a fallback exists

The first fetch against a tokenless URL will fail. Then the fallback kicks in, an authenticated call with getStream against /drives/{drive}/items/{item}/content. That branch never inspects a Location header, and the whole engine tree contains no redirect logic of its own. It does not depend on the redirect, so after the deadline it simply receives the content directly. The download keeps working and costs one wasted attempt per file. For large files the wasted attempt is more expensive, because the chunk loop first rolls the address a few times before it gives up and hands over to the fallback.

Restore: no fallback exists

The restore looks different. The code obtains an upload session through createUploadSession. Three kinds of request then go to that session URL: the chunk PUT with Content-Range and Content-Length, the status query with GET, and the DELETE that releases a failed session. None of the three calls carries an Authorization header, and there is no fallback. If the deadline hits those URLs, the first file aborts with a message that names the HTTP status. The tidying DELETE fails as well, and the session stays reserved until Graph expires it. Three adapters use createUploadSession: files from OneDrive, files from SharePoint sites, and items from Exchange mailboxes. Restoring an older file version goes through a different call, which already sends the Graph token.

What this measurement does not cover

The tenant setting is not switched on in our estate, so the measurement covers code. Which status code an endpoint returns without a token stays open, and whether a backup run loses seconds or minutes per file is open too. A test tenant is the only place that answers those, and it is unavailable while the write syntax is missing.

What to do

  1. Build an inventory of every call across the seven families, with one column asking "Authorization header, yes or no". Both documents supply the template, MC1492958 is the more detailed one.
  2. Move the restore path to a SharePoint token before any other rework. In our console createUploadSession is the only affected path without a fallback, and in a lot of products it is the same one.
  3. Point downloads at the Graph URL with a token, or straight at driveItem/contentStream where it fits. Routing through a SharePoint URL is then redundant.
  4. Retune clients that disable redirects or read Location themselves to the new response shape: content directly, no intermediate step.
  5. Switch binary downloads to an authenticated fetch of the Graph URL instead of unpacking a 302 and forwarding the address.
  6. Early testers should respect the order Deny before Allow before IsDisabled, and start with a single application ID. The documentation explicitly recommends a test tenant before touching a production tenant, and the SharePoint Administrator role is required.
  7. Put the date in the maintenance plan: 1 April 2027 as the deadline, rollout expected to finish in late April 2027.

Further reading

Questions?
Does anything change for people who only use OneDrive in a browser or with the desktop client?+

No. The change applies to program calls against the Microsoft Graph file APIs, meaning applications, integrations and automation. MC1492958 lists the opposite case as a reason to do nothing: an organisation that does not use the affected APIs, and whose applications already call Graph with Microsoft Entra ID tokens, has no action to take.

How do I find affected applications in my own estate?+

Three patterns from the audit list Microsoft published cover most of it. First, code that reads values such as tempauth=, uploadUrl, downloadUrl, getUrl or @microsoft.graph.downloadUrl out of a Graph response and then fetches that address without an Authorization header. Second, HTTP clients with automatic redirect following switched off, or code that inspects the Location header itself. Third, anywhere such an address gets stored in a table or a queue, mailed out, or handed to a browser.

Why is Microsoft doing this?+

The developer blog gives two reasons, and both are vendor statements. A URL is a different storage place than a header: it ends up in logs, in caches and gets forwarded, and a bearer token was never meant for that. Microsoft is also standardising on OAuth tokens from Microsoft Entra ID with a clear audience. The single token in a URL was short-lived and scoped to one object. It simply sat somewhere it should not have been.