M365 SharePoint | tempauth-URLs enden

Microsoft entfernt die vorauthentifizierten URLs, die sogenannten tempauth-URLs, aus SharePoint Online und OneDrive. Ab dem 1. April 2027 geben ausgewählte Graph-File-APIs keine URLs mehr zurück, die Authentifizierungsinformationen eingebettet haben, und senden keine HTTP-302-Weiterleitungen mehr auf solche URLs. Betroffen sind die API-Familien für Download und Content, createUploadSession, Copy-Operationen samt Monitoren, Preview, Thumbnail, Version und Format-Konvertierung.

Der Grund ist Sicherheit. Eine URL mit eingebettetem Token ist ein Zugang, der sich kopieren, zwischenspeichern und einlösen lässt. Künftig erwartet SharePoint Online ein gültiges Entra-ID-Token für die Ressource. Anwendungen, die solche URLs speichern, inspizieren oder einer 302-Weiterleitung folgen, hören auf zu funktionieren, wenn sie bis zum Stichtag nicht umgestellt sind. Eigene Line-of-Business-Apps, Automatisierungen und manche Drittanbieter-Integration fallen in diese Kategorie. Anfragen, die direkt gegen die SharePoint-APIs statt über Graph laufen, sind nicht betroffen.

Es gibt keine Abfrage, die dir die tempauth-Nutzung exakt ausweist. Darum näherst du dich über zwei Signale an: welche Apps überhaupt Graph-File-Berechtigungen haben und welche davon aktiv SharePoint oder OneDrive ansprechen. Verschaff dir zuerst die Liste der Enterprise-Apps und ihrer Dienstprinzipale.

Danach prüfst du je verdächtiger App die erteilten Graph-Berechtigungen (etwa Files.ReadWrite.All, Sites.ReadWrite.All) und die Anmeldeaktivität der App in den Entra-Anmeldeprotokollen. Apps, die regelmäßig gegen Graph-File-Endpunkte arbeiten und dabei Download-, Upload-Session-, Preview- oder Copy-URLs abholen, stehen auf deiner Prüfliste.

Für jede App auf der Liste klärst du drei Fragen. Speichert, inspiziert oder löst die App eine URL mit eingebettetem Token ein? Verlässt sie sich auf eine 302-Weiterleitung, oder kann sie mit einer direkten Content-Antwort umgehen? Kann sie ein gültiges Entra-ID-Token für Graph beziehungsweise die SharePoint-Online-Ressource beschaffen und mitschicken?

Bei eigenentwickelten Apps beantwortet das die Entwicklung, bei Drittanbietern der Hersteller. Hol dir diese Zusagen schriftlich, weil der Fix im Code steckt, nicht in einer Einstellung.

Zur Vorbereitung bekommst du neue SharePoint-Online-Controls, die mit einer kommenden Version der SharePoint-Online-Management-Shell ausgeliefert werden. Damit schaltest du das neue URL-Verhalten pro Anwendungs-ID frei und testest, bevor der Stichtag greift. Die Umstellung ist nicht standardmäßig aktiv, du wählst die App-IDs selbst aus.

Aktivierst du das neue Verhalten für einen kleinen Satz App-IDs, beobachtest du die Anmelde- und Fehlerprotokolle der App genau. Läuft die App sauber mit direkten Content-Antworten und Entra-ID-Token, weitest du die Konfiguration auf weitere Anwendungen aus. Dokumentiere je App den Teststand, damit am Stichtag keine Anwendung übrig bleibt, die niemand geprüft hat.

Anderthalb Jahre Vorlauf wirken großzügig. Für eine eigenentwickelte App mit Freigabeprozess, Testzyklus und Wartungsfenster ist das Fenster knapp, und bei Drittanbietern hängst du am Releaseplan des Herstellers.

Wer die Kandidaten früh kennt und die Herstelleranfragen jetzt startet, hat am Stichtag eine geprüfte Liste statt einer Ausfallmeldung. Die Betriebsseite trägt dieses Thema, nicht die Endnutzer, und genau deshalb geht es im Alltag leicht unter.