[MS] Pre-authenticated (tempauth) URLs are retiring: move to Microsoft Entra ID tokens before April 1, 2027 - devamazonaws.blogspot.com

On April 1, 2027, SharePoint Online and OneDrive will begin removing pre-authenticated URLs, the self-issued tokens SharePoint embeds directly in a URL, commonly seen as the tempauth query parameter. After that date, URLs returned by the affected Microsoft Graph file APIs will require Entra authentication. If your application downloads, uploads, previews, converts, or monitors file operations through Microsoft Graph, now is the time to plan your move to Microsoft Entra ID access tokens.

Key message

URLs returned by the affected Microsoft Graph file APIs will stop carrying embedded authorization. Any URL that previously worked without an Authorization header must now be called with a valid Microsoft Entra ID access token. Where a Microsoft Graph alternative exists, a new tenant setting lets administrators opt your app in to receiving Microsoft Graph URLs you redeem with the Graph token you already hold. Everywhere else, acquire a SharePoint Online token and present it.

Background

Pre-authenticated URLs were designed to support richer user experiences. SharePoint issues a short-lived, single-item token inside the URL so a client can fetch content without a separate authentication round trip. Those tokens are short-lived and scoped to one item.

Standardizing on Microsoft Entra ID-issued OAuth tokens, and removing authentication material from URLs entirely, is the more secure and more predictable model. URLs get logged, cached, forwarded, and stored in ways that bearer tokens in headers do not.

The principle to internalize is simple:

If an API returns a URL that previously worked without authentication because it embedded a token in the URL, that URL must now be accessed by presenting a valid Microsoft Entra ID access token at request time.

In practice, this means the URL itself no longer carries authorization, authorization is enforced through the Authorization header, and tokens are issued by Microsoft Entra ID and scoped to the right audience.

Timeline

  • Today: The opt-in tenant setting for Microsoft Graph URLs is available, so you can validate your app against the new behavior ahead of the change.
  • April 1, 2027: Behavior changes begin. Affected APIs stop returning 302 redirects to pre-authenticated URLs, and SharePoint Online URLs returned in response bodies no longer carry a tempauth token.

Does this affect you?

If your app calls any of the following Microsoft Graph APIs, you have pre-authenticated URL usage today, often without realizing it, because the URL worked without an Authorization header:

A typical pre-authenticated URL looks like this:

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

These APIs fall into two patterns today, and each changes differently.

Pattern What happens now What changes
Redirect The API returns a 302 redirect to a short-lived pre-authenticated URL that needs no Authorization header. No 302 redirections are returned. Your app must not intercept or depend on the redirect; it receives the content directly.
URL in the response body The API returns a short-lived pre-authenticated URL in the response body, callable with no Authorization header. The SharePoint URL in the body is no longer pre-authenticated. You must supply a valid Authorization header with a Microsoft Entra ID access token for SharePoint.

Audit checklist

Go looking for these in your codebase:

  • Code that reads tempauth=, access_token=, uploadUrl, getUrl, @microsoft.graph.downloadUrl, or a monitor URL out of a Graph response and then fetches it without an Authorization header.
  • HTTP clients configured with allowAutoRedirect = false around these calls, or logic that inspects a Location header.
  • Any place a returned URL is persisted (queued, stored in a database, emailed, passed to another service, or handed to a browser) as though it were a durable access artifact.

The path forward

There is presently one supported destinations, and we are introducing another option soon, most apps will use both.

Path A: Call SharePoint Online directly with a Microsoft Entra ID token

Where there is no Graph alternative, the URL you get back is a plain SharePoint Online URL with no embedded token. You acquire a Microsoft Entra ID access token for that host and present it in the Authorization header.

Most flows now involve two tokens: a Microsoft Graph token to call the Graph API, which you already do, and a SharePoint token to access the returned SharePoint URL, which is the new part.

Calling Audience
Microsoft Graph APIs https://graph.microsoft.com
SharePoint Online content URLs https://{tenant}.sharepoint.com

Use delegated access tokens for user-initiated scenarios and app-only access tokens for background or service scenarios. Make sure your app registration in Microsoft Entra ID carries Microsoft Graph permissions such as Files.Read or Files.ReadWrite, plus the equivalent SharePoint Online permissions for the same operations.

Path B: Keep using Microsoft Graph URLs (Coming in future Microsoft SharePoint Online PowerShell versions)

To make the shift easier, a new tenant setting will be available that lets a SharePoint administrator opt specific applications in to receiving Microsoft Graph URLs instead of SharePoint Online or media-service URLs. When it applies, your app keeps using the Microsoft Graph access token it already has: no second token and no new audience.

The setting will be exposed through the existing pre-auth cmdlets in the SharePoint Online Management Shell, using the -UseGraphUrl* switch family:

A few scope and precedence rules are worth knowing before you test:

  • The setting applies only to third-party applications.
  • For supported APIs with a Microsoft Graph URL alternative, the response includes a non-preauthenticated Microsoft Graph URL, and callers must use a Microsoft Graph access token to access it.
  • For APIs without a Microsoft Graph URL alternative, the response continues to include a preauthenticated SharePoint Online URL until the broader deprecation removes the token. Plan for Path A on those.
  • Requests that do not go through Microsoft Graph are unaffected. If you call SharePoint (Vroom) APIs directly, this tenant setting does nothing for you: Graph URLs are returned only when the request originally came through Graph.

Worked examples

Upload session

Previously, createUploadSession returned an uploadUrl carrying a tempauth token, and chunks were uploaded with no authorization header:

POST /drives/{drive-id}/items/{parent-id}:/{filename}:/createUploadSession
{ "uploadUrl": "https://...&tempauth=..." }
PUT {uploadUrl}

Now the same call returns a plain SharePoint Online URL. Acquire a token for the uploadUrl hostname (for example https://{tenant}.sharepoint.com) and present it on every chunk:

{ "uploadUrl": "https://{tenant}.sharepoint.com/..." }
PUT {uploadUrl}
Authorization: Bearer {SharePoint Online access token}

Thumbnails

Previously, a thumbnail content request returned an HTTP 302 whose redirect URL contained tempauth=..., and the thumbnail was then fetched with no Authorization header.

Now you get the thumbnail in a single request, with no redirect to follow and the same Graph token:

GET /drives/{drive-id}/items/{item-id}/thumbnails/0/{size}/content
Authorization: Bearer {Microsoft Graph access token}

Continue to use Microsoft Graph endpoints, ensure requests use Microsoft Entra ID tokens, and avoid redirect-based access that assumes unauthenticated URLs.

Previews

Previously, preview returned a getUrl that carried the pre-auth token, so it was called with no Authorization header:

POST /drives/{driveId}/items/{itemId}/preview
{
  "getUrl": "https://www.onedrive.com/embed?foo=bar&bar=baz",
  "postParameters": "param1=value&param2=another%20value",
  "postUrl": "https://www.onedrive.com/embed_by_post"
}

The call and the response shape are unchanged, but getUrl is now a plain SharePoint URL that must be called with an Authorization header:

GET {getUrl}
Authorization: Bearer {SharePoint Online access token}

driveItem download URL

Previously, a driveItem response carried a pre-authenticated @content.downloadUrl:

{
  "@content.downloadUrl": "https://{tenant}.sharepoint.com/...?tempauth=.."
}

If the tenant SharePoint administrator opts in to the Microsoft Graph URLs capability in the future release of SharePoint Online PowerShell, @content.downloadUrl is now a Microsoft Graph contentStream URL, called with an Authorization header and a Microsoft Entra ID access token for Microsoft Graph:

GET {@content.downloadUrl}
Authorization: Bearer {Microsoft Graph access token}

The full API-by-API behavior mapping (which Graph APIs return Graph URLs, which drop the tempauth token from the SharePoint URL, and which stop issuing 302 redirects) will be maintained in Expected API behavior in Set-SPOTenantPreAuthSettings.

The broader pre-authentication controls

The Graph URL setting will sit alongside the existing pre-authentication controls in the same cmdlet family, which administrators use to disable pre-authentication tenant-wide and then carve out granular exceptions per app and per feature. Two things matter to you as a developer:

  • Deny beats Allow. If an app is on both the allow and deny lists, it gets nothing. See the order of precedence (Deny, then Allow, then IsDisabled).
  • Exceptions are feature-level. Pre-authentication can be allowed or denied per feature: Download, UploadSession, Thumbnail, and more. If your app breaks in a tenant, ask the administrator which features are currently allowed for your app ID; that is often the fastest diagnosis. See the full feature list.

How to migrate

If you build applications or ship an ISV solution:

  1. Inventory every call site that touches the six API families listed above.
  2. Remove all assumptions about 302 redirects: stop intercepting them, and make sure your HTTP client can accept content directly.
  3. Add SharePoint Online token acquisition (audience https://{tenant}.sharepoint.com) alongside your existing Graph token acquisition, and add the SharePoint Online permissions to your app registration.
  4. Stop treating returned URLs as durable access artifacts. Do not store, forward, or queue them for later redemption, and cache Microsoft Entra ID tokens according to standard OAuth guidance instead.
  5. Prefer driveItem/contentStream where you can. It already returns content directly, with no tempauth and no redirect, and is unchanged by any of this.
  6. Test against a test tenant with the setting enabled for your app ID only.
  7. Publish updated minimum-version guidance to your customers well ahead of April 1, 2027.

If you administer a SharePoint Online tenant:

  1. Run Get-SPOTenantPreAuthSettings to see where you stand.
  2. Identify applications that obtain file, version, thumbnail, preview, upload-session, or copy-operation URLs through Microsoft Graph.
  3. Check whether those applications inspect, store, or independently redeem URLs containing temporary authentication information.
  4. Enable the setting for a limited set of application IDs first.
  5. Monitor application behavior and sign-in failures.
  6. Expand the configuration once validation is complete.

Because these settings can disable functionality in a production tenant, evaluate every change in a test tenant first.

No action is required if your organization does not use the affected APIs, or if your applications already use direct Microsoft Graph content endpoints with standard Microsoft Entra ID authentication.

Learn more


Post Updated on October 8, 2026 at 02:10PM
Thanks for reading
from devamazonaws.blogspot.com

Comments

Popular posts from this blog

[MS] Boosting Azure DevOps Security with GHAS Code Scanning - devamazonaws.blogspot.com

[MS] Pulling a single item from a C++ parameter pack by its index, remarks - devamazonaws.blogspot.com

[MS] GitHub Copilot upgrade assistant for Java技术预览发布 - devamazonaws.blogspot.com