Multi-Tenant-Entra-ID-App-Registrierungen für SPFx richtig umsetzen

Von Mirko Peters · 2026-08-11

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Titelbild: Mastering Multi-Tenant Entra ID App Registrations for SPFx

Willkommen zurück zum Podcast! Wenn Sie je versucht haben, eine SharePoint-Framework-(SPFx-)Lösung, die Sie mit viel Sorgfalt in Ihrem eigenen Entwicklungsmandanten gebaut haben, in eine Kundenumgebung zu übertragen, kennen Sie das flaue Gefühl, wenn alles vollständig fehlschlägt. Stille. Leere Webparts. Endlose Anmeldeschleifen. Die mandantenübergreifende Authentifizierung ist die ultimative Bewährungsprobe für Microsoft-365-Entwickler, und sie gelingt nur, wenn Sie die Feinheiten von Entra-ID-App-Registrierungen, dynamischen Bereichen und dem Least-Privilege-Prinzip beherrschen.

In diesem ausführlichen Leitfaden vertiefen wir alles, was wir in unserer neuesten Episode besprochen haben. Um tiefer in das Audiogespräch einzusteigen, hören Sie sich unsere detaillierte Aufschlüsselung unter Fix Multi-Tenant SPFx Authentication an.

Einführung: Warum Multi-Tenant-SPFx der schwere Modus ist

Eine SPFx-Anwendung über Identitätsgrenzen hinweg zu verschieben, wird aus gutem Grund oft als „schwerer Modus“ bezeichnet. Wenn Sie innerhalb eines einzelnen Mandanten entwickeln, sind Entra ID, SharePoint-Websitestrukturen und API-Berechtigungen weitgehend implizit oder lassen sich über globale Administratorrechte leicht umgehen. Sobald Sie ins Multi-Tenant-Modell wechseln, ob als Independent Software Vendor (ISV), der ein Webpart zum Produkt macht, oder als internes IT-Team, das mehrere Tochtermandanten verwaltet, verschwinden diese Abkürzungen.

Sie haben es nun mit strikten Verzeichnisgrenzen, Zustimmungsmodellen, die eine ausdrückliche administrative Genehmigung verlangen, und eigenen Website-Topologien zu tun. Wenn Ihre App-Registrierung als Einzelmandant abgesichert ist oder Ihr Code fest codierte Umgebungsparameter verwendet, schlägt die Bereitstellung in der Produktion mit Sicherheit fehl.

Für wen dieser Leitfaden gedacht ist

Bevor wir in die technischen Details einsteigen, klären wir, wer dieses Architekturmuster beherrschen muss:

SPFx-Entwickler und Microsoft-365-Berater, die für mehrere Mandanten ausliefern, die bei jeder einzelnen Kundenbereitstellung manuelle Neukonfigurationen vermeiden möchten.
IT-Administratoren und MSPs, die SharePoint-Online-Umgebungen von Kunden betreuen, die eine strikte Sicherheitslage aufrechterhalten und zugleich moderne Entwicklerlösungen ermöglichen müssen.
Partner und ISVs, die SPFx-Webparts und -Erweiterungen zum Produkt machen, die einen wiederholbaren, skalierbaren Weg zum Markt über Hunderte unterschiedliche Kundenmandanten benötigen.

Das Wichtigste in Kürze

Damit Sie Multi-Tenant-Bereitstellungen erfolgreich umsetzen, behalten Sie diese Kernprinzipien in Ihrer Architektur im Blick:

Authentifizierung ist kein Standardbaustein: Verwenden Sie eine Multi-Tenant-Entra-ID-App und verlangen Sie die Zustimmung des Administrators pro Mandant. Überprüfen Sie diese Sicherheitszustände zur Laufzeit.
Mandantendetails niemals fest codieren: Laden Sie URLs, IDs und Bereiche dynamisch aus einer mandantenbewussten Konfigurationsquelle. Speichern Sie erforderliche Backend-Geheimnisse sicher in Azure Key Vault.
Leere Graph-Ergebnisse bedeuten nicht automatisch fehlerhaften Code: Wenn Microsoft Graph leere Arrays zurückgibt, liegt das fast immer an fehlender Zustimmung oder abweichenden Verzeichnisdaten und Filtern, nicht an einem Syntaxfehler in Ihrer Codebasis.
Ein Paket, viele Mandanten: Entwerfen Sie Ihre SPFx-Lösungen so, dass sie vollständig mandantenunabhängig sind, und kombinieren Sie sie mit mandantenspezifischen Bereitstellungen, damit keine individuellen Builds pro Kunde nötig sind.
Fehler früh erkennen: Bündeln Sie Telemetrie und Systemzustandsprüfungen mit Application Insights oder Azure Monitor, pro Mandant zugeschnitten.

Highlights

In unserer technischen Untersuchung sind wir auf mehrere kritische Meilensteine gestoßen, die Sie in Ihrem Entwicklungszyklus berücksichtigen sollten:

Die drei Authentifizierungsfehler, die mandantenübergreifende Rollouts scheitern lassen: Einzelmandanten-App-Registrierungen, der Mythos der einmaligen Zustimmung und das direkte Einbetten von Geheimnissen in clientseitigen Code.
Warum Microsoft Graph in Ihrem Entwicklungsmandanten reibungslos funktioniert, in einer Kundenumgebung aber absolut nichts liefert, und wie Sie dies vor dem Go-Live überprüfen.
Einmal paketieren, überall konfigurieren: der Architekturplan für wirklich mandantenunabhängiges SPFx.
Protokollierungs- und Überwachungsstrategien, die stille Konfigurationsprobleme erkennen, bevor Ihre Kunden sie bemerken.
Governance-Strukturen, die Ihre Organisation compliant halten und gleichzeitig ein hohes Liefertempo ermöglichen.

Schnell-Checkliste (zum Kopieren und Einfügen)

Entra-ID-App-Registrierung
- Legen Sie Unterstützte Kontotypen: Mehrinstanzen fest.
- Definieren Sie die exakt benötigten delegierten Graph-Bereiche nach dem Prinzip der geringsten Berechtigung.
- Konfigurieren Sie gültige Umleitungs-URIs, die sowohl SharePoint Online als auch Ihre lokalen Entwicklungsumgebungen abdecken.
SPFx-Projekthärtung
- Verwenden Sie MSGraphClient oder AadHttpClient für alle delegierten API-Aufrufe.
- Lesen Sie mandantenspezifische Konfigurationen (etwa Endpunkte und Ziel-Website-IDs) aus einer dedizierten SharePoint-Konfigurationsliste oder einer gesicherten API. Stellen Sie sicher, dass im Frontend-Code keine Geheimnisse enthalten sind.
- Implementieren Sie Laufzeitprüfungen der Berechtigungen, die bei fehlenden Berechtigungen elegant ein Banner „Administratorzustimmung erforderlich“ mit einem direkten Deep Link anzeigen.
Zustimmungsablauf
- Stellen Sie eine eigene Onboarding-Seite für Mandanten bereit, die die erforderlichen Bereiche, die exakte URL für die Administratorzustimmung und Validierungsschritte anzeigt.
- Unterstützen Sie zielgruppenspezifische Zustimmungsmodelle und unterscheiden Sie zwischen einer unternehmensweiten Einführung und einer gezielten Pilotgruppe.
Paketierung und Bereitstellung
- Paketieren Sie Ihre Lösung einmalig in eine Standard-.sppkg-Datei und aktivieren Sie dort, wo sinnvoll, eine mandantenweite Bereitstellung.
- Veröffentlichen Sie das Paket über einen zentralen App-Katalog und dokumentieren Sie die Schritte für die Hinzufügung auf Website-Ebene gründlich.
- Automatisieren Sie Ihren Release-Zyklus mit einer robusten CI/CD-Pipeline (Build, Bundle, Paketierung, Upload und Bereitstellung).
Überwachung und Support
- Erfassen Sie detaillierte Telemetriedaten, einschließlich Mandanten-ID, Korrelations-ID, einzelner Funktionen und Fehlercodes.
- Richten Sie Application Insights oder Azure-Monitor-Dashboards mit umsetzbaren Warnmeldungen ein.
- Dokumentieren Sie einen klaren Rollback-Prozess mit früheren Paketversionen sowie einer detaillierten Versionszuordnung pro Mandant.

Häufige Fallstricke (und Lösungen)

Selbst erfahrene Entwickler tappen bei der Konfiguration von Mehrmandanten-Anwendungen in vorhersehbare Fallen. So diagnostizieren und beheben Sie diese schnell:

Symptom: Anmeldeschleifen oder das frustrierende Szenario „funktioniert bei mir, nicht bei ihnen“.
Ursache: Ihre Entra-ID-App-Registrierung ist noch als Einzelmandant konfiguriert, oder Ihre Antwort-URLs stimmen nicht mit der Zielumgebung überein.
Lösung: Stellen Sie Ihre App-Registrierung auf Mehrmandant um, korrigieren Sie die Umleitungs-URIs und lösen Sie eine neue Zustimmungsanfrage aus.
Symptom: Microsoft Graph liefert vollständig leere Datensätze zurück.
Ursache: Fehlende Administratorzustimmung des Mandanten oder zu restriktive Verzeichnisfilter.
Lösung: Lösen Sie den passenden Administratorzustimmungsablauf aus, testen Sie Ihre Abfragen direkt im Graph Explorer mit einem echten Benutzer des Kundenmandanten und lockern Sie strikte Annahmen oder Filter in Ihrem Code.
Symptom: Benutzer können den Webpart nicht zu ihren Seiten hinzufügen.
Ursache: Das Paket wurde nicht ordnungsgemäß im Mandanten-App-Katalog bereitgestellt, oder organisationsweite App-Richtlinien blockieren es.
Lösung: Prüfen Sie den Bereitstellungsstatus im App-Katalog sowie die Mandanten-App-Einstellungen und -Richtlinien.
Symptom: Für jede kleine Konfigurationsänderung bei einzelnen Kunden muss das Paket neu erstellt werden.
Ursache: Fest codierte IDs, URLs oder Geheimnisse sind direkt im Bundle eingebettet.
Lösung: Lagern Sie die Konfiguration aus. Nutzen Sie SharePoint-Konfigurationslisten oder Azure Key Vault und lesen Sie diese Werte zur Laufzeit dynamisch aus.

Governance und Sicherheit im Überblick

Sicherheit darf beim Bereitstellen von Code in fremden Kundenmandanten kein nachträglicher Gedanke sein. Implementieren Sie diese Governance-Grundlagen, um Vertrauen zu erhalten:

Setzen Sie das Prinzip der geringsten Berechtigung für Bereiche konsequent durch und führen Sie regelmäßige Überprüfungen der Bereiche durch, um nicht genutzte Berechtigungen zu entfernen.
Speichern Sie Geheimnisse von Backend-Anwendungen sicher in Azure Key Vault und legen Sie einen regelmäßigen Rotationsplan fest.
Nutzen Sie Teams- und SharePoint-App-Berechtigungsrichtlinien, um Zielgruppen gezielt einzuschränken und unbefugte Nutzung zu verhindern.
Führen Sie ein umfassendes Zustimmungsregister, in dem festgehalten wird, wer wann zugestimmt hat und welche Bereiche genehmigt wurden.
Passen Sie das Branding Ihres Webparts dynamisch über die Microsoft-365-Design-APIs an, anstatt mandantenspezifische Formatvorlagen in Ihren Code zu packen.

Validierungsplan (vor der Live-Schaltung beim Kunden)

Stellen Sie niemals ungeprüft bereit. Durchlaufen Sie diesen Validierungsplan, bevor Sie Ihre Lösung einem Kunden präsentieren:

Testen Sie alle Microsoft-Graph-Aufrufe direkt im Kundenmandanten mit dem Graph Explorer, und zwar unter exakt demselben Benutzerkonto und denselben delegierten Bereichen.
Führen Sie eine lokal begrenzte Pilotbereitstellung auf einer einzelnen, isolierten Websitesammlung mit einer kleinen Gruppe ausgewählter Benutzer durch.
Versionsverlauf und Rollback-Möglichkeiten direkt im SharePoint App Catalog überprüfen.
Szenarien mit Offline-Betrieb und abgelaufenen Tokens durchspielen, um zu prüfen, ob Ihre Fehlermeldungen und automatischen Wiederherstellungsabläufe wie erwartet funktionieren.

Häufige Fragen

Benötige ich Anwendungsberechtigungen für SPFx?
In der Regel nicht. SPFx-Lösungen laufen im Kontext des delegierten Benutzers. Anwendungsberechtigungen erfordern zusätzliche administrative Genehmigungen und spezielle Architekturmuster. Verwenden Sie sie nur dann, wenn es keine andere praktikable Alternative gibt.

Kann ich die Zustimmung pro Mandant umgehen?
Nein. Der Administrator jedes Kundenmandanten muss die angeforderten Bereiche Ihrer Anwendung ausdrücklich genehmigen. Sie können diesen Prozess jedoch deutlich vereinfachen, indem Sie geführte Onboarding-Oberflächen und proaktive Hinweisbanner zur Laufzeit einbauen.

Wie pflege ich eine Codebasis für viele Kunden?
Machen Sie Ihre Lösung vollständig mandantenunabhängig, lagern Sie alle umgebungsspezifischen Konfigurationen aus und automatisieren Sie Ihre Paketierungs- und Bereitstellungspipelines. Nutzen Sie Feature-Flags, um kundenspezifische Schalter sicher zu verwalten.

Wie finde ich schneller heraus, warum „alles leer ist“?
Protokollieren Sie die rohen Graph-Antworten zusammen mit den Prüfungen der Bereiche. Tritt ein Fehler auf, zeigen Sie eine Inline-Benachrichtigung mit dem Hinweis „Fehlende Zustimmung oder unzureichender Bereich“ an, ergänzt um einen direkten Deep Link, über den sich das Problem sofort beheben lässt.

Fazit

Die Beherrschung mehrinstanzfähiger Entra ID-App-Registrierungen für SharePoint-Framework-Lösungen trennt Hobby-Skripte von Unternehmenssoftware. Wenn Sie auf mandantenunabhängige Paketierung, dynamisches Laden der Konfiguration und robuste Zustimmungsprüfungen zur Laufzeit setzen, vermeiden Sie stille Bereitstellungsfehler und bieten jedem Kunden ein nahtloses Erlebnis.

Mehr über die praxisnahen Erfahrungen und architektonischen Entscheidungen hinter diesen Lösungen erfahren Sie in der zugehörigen Podcast-Folge: Fix Multi-Tenant SPFx Authentication. Danke fürs Lesen und viel Erfolg beim Programmieren!