OneDrive und SharePoint: Tempauth-URLs verschwinden bis zum 1. April 2027

Am 8. Oktober 2026 hat das Microsoft 365 Developer Blog die Abschaltung der vorauthentifizierten URLs für SharePoint Online und OneDrive angekündigt, laut Seitenmetadaten um 13:10 UTC, als Autor firmiert das SharePoint-Team. Am 9. Oktober ging die Message-Center-Meldung MC1492958 an alle Tenant-Administratoren, im Message Center als Major change und Retirement klassifiziert, Frist 1. April 2027. Der Inhalt in einem Satz: Ab diesem Stichtag enthält keine URL der betroffenen Microsoft-Graph-Datei-APIs mehr ein eingebettetes Token, und die HTTP-Weiterleitung auf eine solche Adresse entfällt ebenfalls.

Was genau wegfällt

SharePoint schrieb bisher ein kurzlebiges Token für genau ein Objekt direkt in die URL, üblicherweise als Query-Parameter tempauth. Ein HTTP-Client konnte diese Adresse ohne Authorization-Header abrufen. Genau das endet. Microsoft zieht die Regel im Entwickler-Blog sichtbar breit: Jede URL, die vorher ohne Authentifizierung funktioniert hat, braucht beim Abruf ein gültiges Access Token von Microsoft Entra ID im Header. Für Aufrufe, die heute mit 302 auf eine vorauthentifizierte Adresse weiterleiten, sagt Microsoft zusätzlich, dass die API den Inhalt dann direkt zurückgibt.

Die API-Referenz selbst sagt davon noch nichts. Die v1.0-Seite zu driveItem: Download content beschreibt (gemessen am 11.10.2026, dort mit dem Stand 27.08.2025 gekennzeichnet) weiterhin die 302-Weiterleitung auf eine vorauthentifizierte URL und schreibt ausdrücklich, dass beim Aufruf der Download-Adresse kein Authorization-Header nötig sei. Wer nur die API-Referenz liest, sieht die Änderung nicht.

Die zwei Umstellungswege

Weg eins ist ein SharePoint-Token. Microsoft stellt für alle betroffenen API-Familien einen OAuth-Flow für die Ressource SharePoint Online bereit, der Tenant-Administrator muss dafür nichts aktivieren. Der Token kommt an jede Anfrage an eine SharePoint-URL, bei einem Upload auch an jedes einzelne Chunk. Das ist der universelle Weg und der einzige, der heute schon dokumentiert funktioniert.

Weg zwei sind Microsoft-Graph-URLs. Für einen Teil der APIs gibt es ein direktes Graph-Gegenstück, etwa driveItem/contentStream für den Download. Dafür führt Microsoft eine Tenant-Einstellung ein, die einem konfigurierten Client statt einer SharePoint-URL eine Graph-URL gibt, die er mit dem Graph-Token abrechnet, den er schon hält. Am Beispiel der Upload-Sitzung zeigt das Blog allerdings Weg eins, also das SharePoint-Token vor jedem Chunk: Für die Upload-URL fehlt das Graph-Gegenstück.

Ein paar Regeln aus der Cmdlet-Dokumentation, die den Ausschlag geben:

1. Eine leere App-Liste in der Einstellung gilt für alle Apps. Der besondere Wert "Empty" steht für Anfragen ohne App-Bezug, etwa aus einem Browser.
2. Die Einstellung gilt nur für Drittanwendungen.
3. Die Reihenfolge ist Deny, dann Allow, dann IsDisabled. Eine Ablehnung schlägt eine Freigabe für dieselbe Anwendung.
4. APIs ohne Graph-Gegenstück bekommen weiter eine vorauthentifizierte SharePoint-URL, und zwar bis die Abschaltung das Token entfernt.
5. Aufrufe, die gar nicht über Graph laufen, bleiben unberührt. Wer die SharePoint-REST-API direkt anspricht, für den ändert die Tenant-Einstellung nichts.

Die Lücke in der Doku, gemessen

Der Timeline-Punkt im Entwickler-Blog behauptet, die Opt-in-Einstellung für Graph-URLs sei verfügbar. Die Überschrift desselben Abschnitts zu Weg zwei sagt (Coming in future Microsoft SharePoint Online PowerShell versions), und MC1492958 schreibt, die Tenant-Controls kämen in einer künftigen Version der SharePoint-Online-PowerShell.

Nachgemessen am 11.10.2026: Die Seite von Set-SPOTenantPreAuthSettings kennt die Parameter dafür nicht. Aufgeführt sind IsDisabled, Type, Add, Remove, Id, IncludedApps, ExcludedApps, IncludedFeatures und ExcludedFeatures, sonst nichts; die Funktionsliste der Seite zählt elf Einträge von DataFormWebpart bis Whiteboard, ohne jeden Hinweis auf Graph-URLs. Der Anker -UseGraphUrlIsEnabled, auf den das Entwickler-Blog verlinkt, existiert auf dieser Seite nicht. Auf der Seite von Get-SPOTenantPreAuthSettings steht der Parametersatz UseGraphUrlSettings dagegen bereits. Auch die Zuordnung, welche Familien ein Graph-Gegenstück haben, fehlt in der Set-Dokumentation.

Geändert wird das im SharePoint-Online-PowerShell-Modul, und die Seiten kommen aus einem öffentlichen Dokumentation repository. Zwei Punkte sind dort in ein paar Minuten nachsehbar: Ob Set-SPOTenantPreAuthSettings.md die UseGraphUrl-Parameter bekommen hat, und ob die Befehlsreferenz die Zuordnungstabelle enthält. Beides war am 11.10.2026 nicht der Fall. Ein Testlauf gegen die eingeschaltete Einstellung ist damit derzeit nicht möglich, weder in einem Test-Tenant noch anderswo. Die Lesefunktion ist dokumentiert, die Schreibfunktion fehlt. Wer es trotzdem versuchen will, beginnt mit Get-SPOTenantPreAuthSettings -UseGraphUrlSettings und sieht, was der Mandant zurückgibt.

Fristen und Rollout

Das Message Center nennt zum Rollout einen Beginn Anfang April 2027 und erwartet den Abschluss Ende April 2027, für Worldwide, GCC, GCC High und DoD. Die Produkt-Doku selbst nennt nur den 1. April 2027 als Beginn der Verhaltensänderung. Wer ein Wartungsfenster plant, sollte die zwei zusätzlichen Wochen einrechnen.

Sieben Familien, sechs Familien, vier Links

MC1492958 zählt sieben Familien auf: Datei-Download und Content, createUploadSession, Kopieren samt Langzeitoperationen und deren Monitor, Vorschau, Miniaturbilder, Versionen und Formatkonvertierung. Der Migrationsschritt im Entwickler-Blog spricht von den sechs weiter oben genannten API-Familien, und die Auswahlüberschrift „Does this affect you?" verlinkt vier Aufrufe. Eine Begründung für die unterschiedliche Zählung liefern beide Dokumente nicht. An der Praxis ändert die Differenz nichts: Wer eine der sieben Familien aufruft, ist betroffen, und die Prüfliste unten gilt für alle.

Eine typische betroffene URL sieht so aus, von Microsoft selbst dokumentiert:

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

Den eigenen Bestand prüfen

1. Code, der tempauth=, access_token=, uploadUrl, getUrl oder @microsoft.graph.downloadUrl aus einer Graph-Antwort liest und die Adresse danach ohne Authorization-Header abholt.
2. HTTP-Clients mit abgeschaltetem Redirect-Following oder mit eigener Auswertung des Location-Headers. Die Antwort kann nach dem Stichtag direkt kommen.
3. Jede langlebig gespeicherte URL in Tabellen, Queues, Reports oder Browserübergaben. Die Kurzlebigkeit war schon vorher ihre Schwäche, ab April 2027 ist sie zwecklos.
4. Range-Downloads. Die Doku empfiehlt heute, den Range-Header auf die eigentliche Download-URL zu setzen. Ab April 2027 gehört der Header auf die Graph-URL, und der Abruf braucht dann den Token.
5. Binary-Downloads, die nach einer aufgelösten 302 einen Datei-Downloader oder Uploader starten.

Messung in unserer M365-Backup-Konsole

Wir betreiben für die Senn-Gruppe eine eigene M365-Backup-Konsole auf dem Backup-Server pbs3, gebaut auf einem Fork eines kommerziellen M365-Backup-Produkts, dessen Upstream-Repository öffentlich auf GitHub liegt. Das ausgeführte Bild heißt m365-console:1.3.2-cbpx und läuft seit dem 7. Oktober. Ich habe den Code im laufenden Container gelesen, nicht den Changelog des Upstreams.

Welche Familien wir aufrufen

Die Engine ruft drei der sieben Familien auf: Download über @microsoft.graph.downloadUrl und über /content, Uploads beim Restore über createUploadSession, Dateiversionen über /versions/{version-id}/content. Die Suchmuster preview, thumbnails, /copy, operations/ und format= liefern im eigenen Engine-Zweig null Treffer. Der Delta-Aufruf selectet @microsoft.graph.downloadUrl für jedes Element und gibt die Adresse an die Pipeline weiter.

Eine URL mit Token landet bei uns nicht auf Platte. Ein Suchlauf über /store/m365/data (6,2 MB, Stand 11.10.2026) findet in keiner Datei ein tempauth. Kurzlebig behandelt die Konsole die URL allerdings schon, weil sie musste: Ein 46-GiB-Objekt ist in unserem Mandant einmal mit HTTP 401 bei 32,8 GiB ausgestiegen, im Wiederholungsversuch bei 22,7 GiB, jeweils nach rund 65 Minuten Übertragung. Seither wird die Adresse spätestens alle zwei Minuten neu geholt und bei jedem 401 sofort ersetzt, pro Chunk bis zu dreimal, bei fünf Netzwerkversuchen je Chunk.

Download: Fallback vorhanden

Der erste Abruf auf einer URL ohne Token wird fehlschlagen. Danach greift der Fallback, eine authentifizierte Anfrage mit getStream auf /drives/{drive}/items/{item}/content. Dieser Zweig wertet keinen Location-Header aus, und im gesamten Engine-Zweig findet sich keine eigene Redirect-Logik. Er hängt also nicht an der Weiterleitung und bekommt nach dem Stichtag den Inhalt direkt. Der Download läuft weiter und ist pro Datei um einen erfolglosen Versuch teurer. Bei großen Dateien ist der Fehlversuch teurer, weil die Chunkschleife erst die Adresse nachholt und dann aufgibt, ehe der Fallback einspringt.

Restore: kein Fallback vorhanden

Beim Restore sieht es anders aus. Die Session holt sich der Code über createUploadSession. Danach gehen drei Arten von Anfragen an die Session-URL: der Chunk-PUT mit Content-Range und Content-Length, die Statusabfrage per GET und das DELETE, das eine fehlgeschlagene Sitzung freigibt. In allen drei Aufrufen steht kein Authorization-Header, und es gibt keinen Fallback. Trifft der Stichtag diese URLs, bricht die erste Datei mit einer Meldung ab, die den HTTP-Status nennt. Das aufräumende DELETE schlägt dann ebenfalls fehl, die Sitzung bleibt reserviert, bis Graph sie verwirft. Betroffen sind die drei Adapter, die createUploadSession benutzen: Dateien aus OneDrive, Dateien aus SharePoint-Websites und Elemente aus Exchange-Postfächern. Die Wiederherstellung einer alten Dateiversion führt über einen anderen Aufruf, der den Graph-Token bereits mitschickt.

Was diese Messung nicht leistet

Die Tenant-Einstellung ist bei uns nicht eingeschaltet, gemessen ist der Code. Welche Zahl ein Endpoint ohne Token antwortet, ist damit offen, und ob das Backup pro Datei Minuten oder Sekunden verliert, auch. Der Testlauf im Test-Tenant ist die einzige Instanz, die diese Punkte klärt, und der steht wegen der fehlenden Schreib-Syntax noch nicht zur Verfügung.

Was zu tun ist

1. Bestandsliste aller Aufrufe über die sieben Familien, mit einer Spalte „Authorization-Header ja oder nein". Die Vorlage dafür haben beide Dokumente, MC1492958 ist ausführlicher.
2. Restore-Pfad auf SharePoint-Token umstellen, vor allen anderen Umbauten. Bei uns ist createUploadSession der einzige betroffene Pfad ohne Fallback, und in vielen Produkten ist er das auch.
3. Downloads auf die Graph-URL mit Token legen, oder direkt auf driveItem/contentStream, wo es passt. Der Umweg über eine SharePoint-URL ist dann überflüssig.
4. Clients, die Weiterleitungen abschalten oder Location selbst auswerten, auf die neue Antwortform umstellen: Inhalt direkt, kein Zwischenschritt.
5. Binary-Downloads auf authentifizierten Abruf der Graph-URL umstellen, statt eine 302 aufzureißen und die Adresse weiterzureichen.
6. Wer zu den frühen Testern gehören will, beachtet die Reihenfolge Deny vor Allow vor IsDisabled und beginnt mit einer einzigen App-ID. Die Doku empfiehlt ausdrücklich einen Test-Tenant vor jedem Eingriff in den Produktivmandanten, und die Rolle SharePoint Administrator ist nötig.
7. Frist im Wartungsplan eintragen: Stichtag 1. April 2027, erwartetem Abschluss des Rollouts Ende April 2027.

Weiterführende Quellen

• Microsoft 365 Developer Blog, 8. Oktober 2026, mit Prüfliste, API-Mustern und Codebeispielen: https://devblogs.microsoft.com/microsoft365dev/pre-authenticated-tempauth-urls-are-retiring-move-to-microsoft-entra-id-tokens-before-april-1-2027/
• Microsoft 365 Message Center MC1492958, 9. Oktober 2026, im öffentlichen Mirror mc.merill.net; das Original steckt hinter dem Tenant-Login: https://mc.merill.net/message/MC1492958
• Dokumentierte Schreibseite der Tenant-Einstellung, ohne die Graph-URL-Parameter, gemessen am 11.10.2026: https://learn.microsoft.com/en-us/powershell/module/microsoft.online.sharepoint.powershell/set-spotenantpreauthsettings?view=sharepoint-ps
• Lesende Seite mit dem Parametersatz UseGraphUrlSettings: https://learn.microsoft.com/en-us/powershell/module/microsoft.online.sharepoint.powershell/get-spotenantpreauthsettings?view=sharepoint-ps
• Dazugehöriges Clear-SPOTenantPreAuthSettings: https://learn.microsoft.com/en-us/powershell/module/microsoft.online.sharepoint.powershell/clear-spotenantpreauthsettings?view=sharepoint-ps
• Die Download-API in ihrer heutigen Form, mit dem dokumentierten 302-Verhalten: https://learn.microsoft.com/en-us/graph/api/driveitem-get-content?view=graph-rest-1.0