Multi-tenant Entra ID-app-registraties voor SPFx onder de knie krijgen

By Mirko Peters · 2026-08-11

Welkom terug bij de podcast! Als je ooit hebt geprobeerd een SharePoint Framework (SPFx)-oplossing die met veel zorg in je eigen ontwikkeltenant is gebouwd naar een klantomgeving uit te rollen, ken je het zinkende gevoel wanneer alles volledig misgaat. Stilte. Lege webparts. Eindeloze inlusslussen. Cross-tenant-authenticatie is de ultieme proef voor Microsoft 365-ontwikkelaars, en om die goed te k

Automatically translated with AI from the original post. Read the English original

Welkom terug bij de podcast! Als je ooit hebt geprobeerd een SharePoint Framework (SPFx)-oplossing die met veel zorg in je eigen ontwikkeltenant is gebouwd naar een klantomgeving uit te rollen, ken je het zinkende gevoel wanneer alles volledig misgaat. Stilte. Lege webparts. Eindeloze inloglussen. Cross-tenant-authenticatie is de ultieme proef voor Microsoft 365-ontwikkelaars, en om die goed te krijgen moet je de finesses van Entra ID-app-registraties, dynamische scopes en beveiliging met minimale rechten beheersen.

In deze uitgebreide gids bouwen we verder op alles wat we in onze laatste aflevering hebben besproken. Wil je dieper ingaan op het audiogesprek? Luister dan naar onze gedetailleerde uitleg over Fix Multi-Tenant SPFx Authentication.

Inleiding: waarom multi-tenant SPFx een uitdaging is

Een SPFx-applicatie over identiteitsgrenzen heen verplaatsen wordt niet voor niets vaak "hard mode" genoemd. Wanneer je binnen één tenant bouwt, zijn Entra ID, de SharePoint-sitestructuren en API-machtigingen grotendeels impliciet of makkelijk te omzeilen via globale beheerdersrechten. Zodra je in een multi-tenantmodel stapt, of je nu een Independent Software Vendor (ISV) bent die een webpart op de markt brengt of een interne IT-afdeling die meerdere dochtertenants beheert, verdwijnen die kortere wegen.

Je krijgt nu te maken met strikte directorygrenzen, toestemmingsmodellen die expliciete goedkeuring van een beheerder vereisen, en unieke sitetopologieën. Als je app-registratie is vastgezet als single-tenant, of als je code vastgelegde omgevingsparameters bevat, dan faalt je uitrol in productie gegarandeerd.

Voor wie is dit bedoeld?

Voordat we in de technische details duiken, bepalen we eerst wie deze architectuurpatroon moet beheersen:

• SPFx-ontwikkelaars en Microsoft 365-consultants die naar meerdere tenants uitleveren die handmatige herconfiguratie voor elke afzonderlijke klantimplementatie willen vermijden.
• IT-beheerders en MSP's die klant-SharePoint Online-omgevingen ondersteunen die een strikte beveiligingshouding moeten handhaven en tegelijk moderne oplossingen voor ontwikkelaars mogelijk maken.
• Partners en ISV's die SPFx-webparts en -extensies op de markt brengen die een herhaalbaar, schaalbaar pad naar de markt nodig hebben over honderden verschillende klanttenants heen.

Belangrijkste punten

Om multi-tenantimplementaties succesvol te doorlopen, houd je deze kernprincipes steeds in het oog bij je architectuur:

• Authenticatie is geen standaardcode: gebruik een multi-tenant Entra ID-app en vereis toestemming per tenant door een beheerder; controleer deze beveiligingsstatussen tijdens runtime.
• Hardcode nooit tenantgegevens: laad URL's, ID's en scopes dynamisch uit een tenantbewuste configuratiebron; sla eventuele benodigde backend-geheimen veilig op in Azure Key Vault.
• Lege Graph-resultaten betekenen niet dat de code kapot is: wanneer Microsoft Graph lege arrays retourneert, komt dat bijna altijd door ontbrekende toestemming of niet-overeenkomende directorygegevens en filters, en niet door een syntaxisfout in je codebase.
• Eén pakket, vele tenants: ontwerp je SPFx-oplossingen volledig tenant-agnostisch en combineer ze met tenantgebonden implementaties, zodat je geen aangepaste builds per klant meer nodig hebt.
• Zie fouten vroeg: centraliseer telemetrie en statuscontroles met Application Insights of Azure Monitor, per tenant ingericht.

Highlights

Tijdens onze technische verkenning hebben we verschillende belangrijke mijlpalen bereikt waar je in je ontwikkelcyclus rekening mee moet houden:

• De drie authenticatiefouten die cross-tenant-uitrollen laten mislukken, waaronder single-tenant app-registraties, het mythe van de eenmalige toestemming en het insluiten van geheimen direct in client-side code.
• Waarom Microsoft Graph naadloos werkt in je ontwikkeltenant maar in een klantomgeving absoluut niets teruggeeft, en hoe je dat valideert vóór go-live.
• Eénmaal inpakken, overal configureren: de architectuurblauwdruk voor echt tenant-agnostische SPFx.
• Logging- en monitoringstrategieën die stille configuratieproblemen opvangen voordat je klanten ze ooit opmerken.
• Governancestructuren die je organisatie compliant houden en tegelijk een hoog leveringstempo behouden.

Snelle checklist (kopiëren/plakken)

1. Entra ID-app-registratie
   • Stel Ondersteunde accounttypen: Multitenant in.
   • Bepaal de exacte gedelegeerde Graph-scopes die je nodig hebt, volgens het principe van least privilege.
   • Configureer geldige redirect-URI's voor zowel SharePoint Online als je lokale ontwikkelomgevingen.
2. SPFx-projectverharding
   • Gebruik MSGraphClient of AadHttpClient voor alle gedelegeerde API-aanroepen.
   • Lees tenantspecifieke configuraties (zoals endpoints en doelsite-ID's) uit een speciale SharePoint-configuratielijst of een beveiligde API. Zorg dat er geen enkele geheime sleutel in de frontendcode staat.
   • Implementeer controles op machtigingen tijdens runtime, zodat een banner ‘Beheerderstoestemming vereist’ netjes wordt weergegeven met een directe deep link wanneer machtigingen ontbreken.
3. Toestemmingsproces
   • Maak een aparte onboardingpagina voor de tenant met de vereiste scopes, de exacte URL voor beheerderstoestemming en de validatiestappen.
   • Ondersteun toestemmingsmodellen per doelgroep, met onderscheid tussen een uitrol voor de hele organisatie en een gerichte pilotgroep.
4. Verpakking en implementatie
   • Verpak je oplossing één keer in een standaard .sppkg-bestand en schakel waar zinvol implementatie op tenantniveau in.
   • Publiceer via een centrale App Catalog en documenteer grondig de stappen om de app op siteniveau toe te voegen.
   • Automatiseer je releasecyclus met een robuuste CI/CD-pipeline (build, bundle, package, upload en deploy).
5. Monitoring en ondersteuning
   • Verzamel uitgebreide telemetrie, inclusief tenant-ID, correlatie-ID, specifieke functies en foutcodes.
   • Koppel Application Insights of Azure Monitor-dashboards aan bruikbare waarschuwingen.
   • Documenteer een duidelijke rollbackprocedure met behulp van eerdere pakketversies, samen met een gedetailleerd versieoverzicht per tenant.

Veelvoorkomende valkuilen (en oplossingen)

Ook ervaren ontwikkelaars trappen regelmatig in voorspelbare valkuilen bij het configureren van multitenant-applicaties. Hier lees je hoe je ze snel herkent en oplost:

• Symptoom: Inlusppen of het frustrerende ‘werkt voor mij, niet voor hen’-scenario.
  Oorzaak: Je Entra ID-app-registratie staat nog ingesteld op single-tenant, of je reply-URL's komen niet overeen met de doelomgeving.
  Oplossing: Zet je app-registratie om naar multitenant, corrigeer je redirect-URI's en start een nieuwe toestemmingsaanvraag.
• Symptom: Microsoft Graph retourneert volledig lege datasets.
  Oorzaak: Ontbrekende toestemming van de tenantbeheerder, of te strikte directoryfilters.
  Oplossing: Start het juiste toestemmingsproces van de beheerder, test je query's rechtstreeks in Graph Explorer met een echte gebruiker uit de klanttenant en versoepel strikte aannames of filters in je code.
• Symptom: Gebruikers kunnen de webpart niet aan hun pagina's toevoegen.
  Oorzaak: Het pakket is niet correct geïmplementeerd in de app-catalogus van de tenant, of organisatiebrede app-beleidsregels blokkeren het.
  Oplossing: Controleer de status van de implementatie in de App Catalog en bekijk de app-instellingen en het beleid van de tenant.
• Symptom: Je moet het pakket opnieuw bouwen voor elke kleine configuratiewijziging bij verschillende klanten.
  Oorzaak: Hardgecodeerde ID's, URL's of geheime sleutels zitten rechtstreeks in de bundle.
  Oplossing: Haal de configuratie uit de code; gebruik SharePoint-configuratielijsten of Azure Key Vault en lees deze waarden dynamisch tijdens runtime.

Essentials voor governance en beveiliging

Beveiliging kan niet achteraf worden toegevoegd wanneer je code uitrolt in externe klantomgevingen. Implementeer deze essentials voor governance om het vertrouwen te behouden:

• Dwing scopes met least privilege af en voer regelmatig scopecontroles uit om ongebruikte machtigingen te verwijderen.
• Bewaar geheime sleutels van backend-applicaties veilig in Azure Key Vault en stel een vast schema voor rotatie vast.
• Gebruik Teams- en SharePoint-app-machtigingsbeleid om doelgroepen strikt te beperken en ongeautoriseerd gebruik te voorkomen.
• Houd een uitgebreid toestemmingsregister bij, met wie toestemming heeft gegeven, wanneer die toestemming is verleend en welke scopes zijn goedgekeurd.
• Stem de huisstijl van je webpart dynamisch af via de Microsoft 365-thema-API's, in plaats van tenantspecifieke stijlbestanden in je code op te nemen.

Validatieplan (vóór livegang bij de klant)

Implementeer nooit blindelings. Doorloop dit validatieplan voordat je je oplossing aan een klant presenteert:

• Test alle Microsoft Graph-aanroepen rechtstreeks in de klanttenant via Graph Explorer, met exact dezelfde gebruikersaccount en gedelegeerde scopes.
• Voer een gelokaliseerde pilotimplementatie uit op één geïsoleerde sitecollectie met een kleine groep gerichte gebruikers.
• Controleer de versiegeschiedenis en de herstelmogelijkheden rechtstreeks in de SharePoint App Catalog.
• Test scenario's met offline gebruik en verlopen tokens, zodat je kunt bevestigen dat je foutmeldingen en automatische herstelprocessen werken zoals verwacht.

Veelgestelde vragen

Heb ik applicatiemachtigingen nodig voor SPFx?
Meestal niet. SPFx-oplossingen worden uitgevoerd binnen de context van een gedelegeerde gebruiker. Applicatiemachtigingen vereisen extra goedkeuringen van beheerders en specifieke architectuurpatronen. Gebruik ze dus alleen wanneer er geen andere werkbare optie is.

Kan ik toestemming per tenant vermijden?
Nee. De beheerder van elke klanttenant moet de gevraagde scopes van je applicatie expliciet verlenen. Je kunt dit proces wel aanzienlijk vereenvoudigen door begeleide onboardingschermen te bouwen en proactieve banners met meldingen tijdens runtime te tonen.

Hoe houd ik één codebase voor veel klanten?
Maak je oplossing volledig tenant-agnostisch, externaliseer alle omgevingsspecifieke configuraties en automatiseer je verpakkings- en implementatiepijplijnen. Gebruik feature flags om klantspecifieke schakelaars veilig te beheren.

Hoe stel ik sneller vast waarom "er niets verschijnt"?
Log ruwe Graph-responses samen met controles op scopes. Wanneer er een fout optreedt, toon je een melding in de pagina met de tekst "Ontbrekende toestemming of onvoldoende scope", met een directe deeplink om het probleem meteen op te lossen.

Conclusie

Het beheersen van multi-tenant Entra ID-app-registraties voor SharePoint Framework-oplossingen is wat hobbyscripts scheidt van softwareproducten van enterprise-niveau. Door je denkwijze te richten op tenant-agnostische verpakking, dynamisch laden van configuratie en robuuste validatie van toestemming tijdens runtime, voorkom je stille implementatiefouten en lever je voor elke klant een naadloze ervaring.

Wil je meer horen over de praktijkverhalen en architectuurbeslissingen achter deze oplossingen? Bekijk dan zeker de bijbehorende podcastaflevering: Fix Multi-Tenant SPFx Authentication. Bedankt voor het lezen en veel plezier met coderen!