Gedelegeerde versus toepassingsmachtigingen: het juiste model kiezen voor je app

By Mirko Peters · 2026-08-11

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

Titelbild: Delegated vs. Application Permissions: Choosing the Right Model for Your App

Welkom terug bij de podcast en onze doorlopende serie die je helpt om Microsoft 365, Azure en de developertools van het moderne cloudecosysteem onder de knie te krijgen. Als je ooit een integratie hebt gebouwd, een script hebt geschreven of enterprise-automatisering hebt uitgerold met de Microsoft Graph API, dan ben je ongetwijfeld tegen de machtigingsmuur aangelopen. Je tenant beveiligen en tegelijkertijd functionele apps bouwen is een van de belangrijkste evenwichtsoefeningen waar je als beheerder of developer mee te maken krijgt. Het kiezen tussen verschillende machtigingsmodellen heeft rechtstreeks invloed op je beveiligingspositie, de snelheid van uitrol en de algehele systeemarchitectuur.

Om dit onderwerp verder uit te diepen, hebben we onlangs een diepgaande aflevering opgenomen. Bekijk zeker de volledige audiodiscussie via Microsoft Graph Permissions and Consent Models Explained. In deze begeleidende blogpost gaan we dieper in op die concepten: we bespreken de kernverschillen tussen gedelegeerde en toepassingsmachtigingen, we bekijken de toestemmingsmodellen, we behandelen best practices en we geven een uitgebreid kader zodat je apps veilig en compliant blijven.

Overzicht van Microsoft Graph API-machtigingen

Voordat we ingaan op de nuances van specifieke autorisatiestromen, is het goed om te begrijpen wat Microsoft Graph API-machtigingen eigenlijk zijn. Microsoft Graph fungeert in de kern als een uniforme toegangspoort tot gegevens die zich bevinden in Microsoft 365-diensten, waaronder Exchange Online, SharePoint, Microsoft Teams, OneDrive en Azure Active Directory (Microsoft Entra ID). In plaats van dat developers zich moeten authenticeren bij meerdere afzonderlijke eindpunten, biedt Microsoft Graph één REST API-eindpunt. Omdat deze API toegang geeft tot vrijwel elk onderdeel van de digitale omgeving van een organisatie, is een robuust, granulair machtigingskader essentieel om hem te beveiligen.

Gedelegeerde versus toepassingsmachtigingen

Wanneer je een app registreert in het Microsoft identity platform, moet je expliciet aangeven hoe je app met resources wil communiceren. Dat komt in essentie neer op een keuze tussen twee primaire machtigingstypen: gedelegeerde machtigingen en toepassingsmachtigingen. Deze keuze bepaalt hoe je applicatie zich authenticeert, namens wie of wat ze handelt en welke grenzen gelden voor de gegevens die ze kan ophalen.

Gedelegeerde machtigingen zijn bedoeld voor client-side of gebruikersgerichte toepassingen, zoals single-page webapps, mobiele apps of desktophulpprogramma's, waarbij een aangemelde gebruiker actief aanwezig is. In dit model handelt je app *namens* de gebruiker. De toepassing kan alleen gegevens benaderen en acties uitvoeren waarvoor de gebruiker zelf de rechten heeft. Wanneer een gebruiker de app start, wordt hij of zij gevraagd zich aan te melden en expliciet toestemming te geven. Daarmee wordt een OAuth 2.0-toegangstoken uitgegeven dat zowel de identiteit van de gebruiker als de toegekende scopes bevat.

Toepassingsmachtigingen worden daarentegen gebruikt door achtergrondservices, daemons, webjobs en geautomatiseerde runbooks die onafhankelijk van een gebruikerscontext werken. Hier draait de app onder haar eigen identiteit. Ze gebruikt clientreferenties, zoals een clientgeheim, een publiek/privé-certificaatpaar of een beheerde identiteit, om een app-only toegangstoken van Azure AD op te halen. Omdat er geen mens achter het toetsenbord zit om zich te authenticeren, gelden deze machtigingen voor resources op tenantniveau. Daardoor brengen ze aanzienlijk hogere beveiligingsrisico's met zich mee en vereisen ze altijd expliciete toestemming van een tenantbeheerder.

Belangrijkste verschillen en gebruikssituaties

Weten wanneer je welk machtigingsmodel inzet, voorkomt architectuurknelpunten en beveiligingskwetsbaarheden. Laten we eens kijken naar een korte vergelijking:

Gedelegeerde machtigingen: De app werkt voor een gebruiker. De gebruiker moet zich aanmelden en toestemming geven. De app kan alleen zien wat de gebruiker kan zien. Dit model is ideaal voor clientapps die persoonlijke gegevens lezen of schrijven, zoals individuele agenda's of e-mails.
Toepassingsmachtigingen: De app werkt als zichzelf. Geen enkele gebruiker hoeft zich aan te melden. Een beheerder moet toestemming geven. De app kan gegevens in de hele tenant bekijken en wijzigen. Dit model is ideaal voor achtergrondsynchronisatie, administratieve rapportage en geautomatiseerde governancetaken.

De juiste keuze hangt volledig af van de architectuur van je applicatie. Als je bijvoorbeeld een interactief dashboard bouwt dat het profiel en de persoonlijke postbus van een gebruiker toont, moet je gedelegeerde machtigingen gebruiken. Als je daarentegen een geautomatiseerd script ontwikkelt dat om middernacht alle postbussen in de organisatie scant voor compliance-audits, zijn toepassingsmachtigingen nodig.

Gedelegeerde machtigingen in Microsoft Graph

Hoe gedelegeerde machtigingen werken

Gedelegeerde toegang is nauw verweven met de identiteit van de gebruiker. Wanneer je applicatie een gedelegeerde machtiging aanvraagt, vraagt ze de autorisatieserver eigenlijk om toestemming om binnen vastgelegde grenzen de aangemelde gebruiker na te bootsen. Het toegangstoken dat via de OAuth-autorisatiecodestroom wordt teruggegeven, bevat specifieke scopeclaims die zowel de eigen rechten van de gebruiker als de aangevraagde machtigingen van de applicatie weerspiegelen.

Gedelegeerde toegang betekent dat je app rechtstreeks als de gebruiker handelt.
Zowel de app-registratie als de individuele gebruiker moeten beschikken over de juiste onderliggende rechten.
Scopes bepalen het exacte maximum van wat je app namens de gebruiker kan doen.
Het resulterende toegangstoken koppelt de app-identiteit en de gebruikerscontext aan elkaar.

Veelvoorkomende scenario's voor gedelegeerde machtigingen

Gedelegeerde machtigingen vormen de basis van de meeste dagelijkse productiviteitsintegraties. Als een zakelijke notitie-app bijvoorbeeld bestanden moet synchroniseren met de OneDrive van een gebruiker, vraagt ze de scope Files.ReadWrite aan. Als de gebruiker geen toegang heeft tot een specifiek document, wijst de Graph API het verzoek af, ook al staat de scope van de app dat technisch gezien toe. Apps die de Microsoft Graph SDK gebruiken om namens een gebruiker geautomatiseerde e-mailmeldingen te versturen, maken op vergelijkbare wijze gebruik van gedelegeerde scopes zoals Mail.Send.

Overwegingen over beveiliging en toestemming

Gedelegeerde machtigingen zijn van nature veiliger dan machtigingen voor de hele tenant, omdat ze gebonden zijn aan de beperkingen van de gebruiker. Toch brengen ze eigen beveiligingsuitdagingen met zich mee. Als een applicatie te brede scopes aanvraagt, zoals volledige toegang tot de hele postbus en het directoryprofiel van een gebruiker, dan kan een geslaagde phishingaanval of een gecompromitteerde app gevoelige persoonsgegevens blootstellen. Ontwikkelaars moeten strikt het principe van de minste privilege hanteren en alleen de specifieke scopes aanvragen die nodig zijn voor de directe functionaliteit.

Toepassingsmachtigingen in Microsoft Graph

Hoe toepassingsmachtigingen werken

Toepassingsmachtigingen halen het menselijke element uit de authenticatievergelijking. In plaats van een aanmeldingsvenster te gebruiken, authenticeert de applicatie zich rechtstreeks bij Microsoft Entra ID met clientreferenties. Het resulterende token bevat app-rollen in plaats van gedelegeerde scopes, waardoor de serviceprincipal brede, onbeperkte toegang krijgt tot resources in de hele tenant.

Toepassingsmachtigingen werken volledig zonder aangemelde gebruiker.
De applicatie haalt een app-only token op om resources te bevragen.
De toegang wordt bepaald door de app-rollen die aan de serviceprincipal zijn toegewezen, en niet door individuele gebruikersrechten.

Wanneer toepassingsmachtigingen gebruiken

Beperk toepassingsmachtigingen strikt tot backend-workloads, onbeheerde daemons en systeem-naar-systeem-integraties. Denk aan geautomatiseerde engines voor gebruikersprovisioning, gecentraliseerde back-upsystemen, tools voor respons op beveiligingsincidenten en scripts voor tenantmigratie.

Beheerderstoestemming en beveiligingsgevolgen

Omdat toepassingsmachtigingen de beperkingen van individuele gebruikers omzeilen en toegang tot de hele tenant geven, kunnen gewone gebruikers er geen toestemming voor geven. Alleen een bevoegde beheerder kan toestemming voor toepassingsmachtigingen verlenen. Verkeerd geconfigureerde toepassingsmachtigingen, zoals het verlenen van Directory.ReadWrite.All of Mail.ReadWrite.All aan een onbetrouwbare of slecht geschreven achtergrond-app, kunnen een volledige Microsoft 365-tenant kwetsbaar maken voor totale compromittering. Controleer je service-principals van bedrijfsapplicaties daarom regelmatig.

Voor- en nadelen van Microsoft Graph API-machtigingen

Voordelen

Uniform machtigingsmodel: Eén consistent autorisatiekader voor alle Microsoft 365-diensten vereenvoudigt het beheer.
Fijnmazige scopes: Gedetailleerde gedelegeerde en toepassingsscopes maken precieze architecturen met minimale privileges mogelijk.
Standaard OAuth2/OpenID Connect: Gebruikt industriestandaard beveiligingsprotocollen voor eenvoudige identiteitsintegratie.
RBAC-integratie: Haakt naadloos aan op Azure AD-rollen en voorwaardelijk toegangsbeleid voor gecentraliseerde compliance.
Incrementele toestemming: Laat apps na verloop van tijd extra machtigingen aanvragen in plaats van alles vooraf te eisen.

Nadelen

Complexiteit: Het doorgronden van het samenspel tussen gedelegeerde scopes, app-rollen en toestemmingsmodellen voor beheerders kan nieuwkomers overweldigen.
Risico's bij hoge bevoegdheden: Een verkeerd geconfigureerde brede machtiging (zoals Sites.FullControl.All) kan enorme hoeveelheden bedrijfsgegevens blootstellen.
Knelpunten bij toestemming door beheerders: Wanneer voor machtigingen met grote impact goedkeuring van een beheerder nodig is, kan dat agile ontwikkelcycli vertragen.
Versnipperde documentatie: Ontwikkelaars moeten vaak meerdere Microsoft-documentatiebronnen naast elkaar leggen om het exacte API-gedrag in kaart te brengen.

Toestemmingsmodellen en best practices

Gebruikerstoestemming versus beheerderstoestemming in Microsoft Graph

Het goed beheren van hoe toestemming wordt verkregen, is essentieel voor organisatiebrede governance. Met gebruikerstoestemming kunnen individuen apps machtigen om toegang te krijgen tot hun persoonlijke gegevens. Met beheerderstoestemming verschuift het goedkeuringsmoment naar IT-beheerders, die app-aanvragen namens de hele organisatie beoordelen. Moderne beveiligingsbaselines schakelen gebruikerstoestemming vaak volledig uit, zodat alle onboarding van applicaties verloopt via een formeel goedkeuringsproces vooraf door een beheerder.

Impact van tenantbeleid op machtigingen

Tenantbeleid van een organisatie kan bepalen hoe je app zich tijdens runtime gedraagt. Als een beheerder strikte voorwaardelijke toegangsbeleidsregels heeft afgedwongen, zoals verplichte multifactorauthenticatie (MFA) of compliant, hybride Azure AD-gejoinde apparaten, dan wordt een app die een Graph-token probeert op te halen zonder aan die criteria te voldoen, geblokkeerd. Ontwikkelaars moeten hun applicaties dus zo ontwerpen dat fouten bij het verkrijgen van tokens netjes worden afgehandeld en duidelijke stappen voor herstel worden getoond.

Strategieën voor een soepele toestemmingsstroom

Plan je machtigingsstrategie om gebruikersfrictie en blokkades door beheerders te voorkomen, nog vóór je code schrijft. Implementeer incrementele toestemmingspatronen waarbij je app vooraf alleen basale identiteitsscopes vraagt, en specifieke resourcemachtigingen pas vraagt wanneer de gebruiker naar die specifieke functies navigeert. Gebruik geautomatiseerde vooraf-goedkeuringsworkflows in Microsoft Entra ID om de ontwikkeling te stroomlijnen en tegelijk strikt toezicht op de beveiliging te behouden.

Veelgemaakte fouten met machtigingen in de Microsoft Graph API

Gedelegeerde en applicatiemachtigingen door elkaar halen en de vereisten rond gebruikerscontext verkeerd inschatten.
Vooraf te veel machtigingen aanvragen in plaats van een least-privilege-aanpak te volgen.
Geen rekening houden met de vereisten voor toestemming door beheerders bij het uitrollen van achtergrondservices.
Aannemen dat wijzigingen in machtigingen in de Azure-portal meteen ingaan zonder dat het token wordt vernieuwd.
Een gedelegeerd toegangstoken aanbieden terwijl een clientcredentials-token vereist is.
Voorwaardelijke toegangsbeleidsregels negeren die Graph API-aanvragen tijdens runtime blokkeren.
Nalaten om scope-claims tijdens runtime in de applicatiecode te valideren.
Nalaten om toegekende applicatiemachtigingen en serviceprincipals na verloop van tijd te controleren.

Checklist machtigingen Microsoft Graph API

Gebruik deze praktische checklist om je team door het ontwerpen, implementeren en controleren van machtigingen in de Microsoft Graph API veilig heen te loodsen:

Conclusie

Het begrijpen van machtigingen in de Microsoft Graph API hoeft geen frustrerende klus te zijn. Door de operationele verschillen goed te begrijpen tussen gedelegeerde machtigingen (die een aangemelde gebruiker vereisen en binnen de beperkingen van die gebruiker werken) en applicatiemachtigingen (die zonder beperkingen op de achtergrond draaien en beheerderstoestemming vereisen), kun je veilige, schaalbare oplossingen bouwen. Door het least-privilege-principe toe te passen, streng te auditen en bedrijfsbrede governance-tools in te zetten, houd je je Microsoft 365-omgeving veilig zonder de innovatie te vertragen.

Voor meer expertadvies, praktijkstrategieën en diepgaande verhalen over het beveiligen van je cloudomgeving: luister zeker naar onze volledige audiobespreking van de bijbehorende aflevering: Microsoft Graph Permissions and Consent Models Explained. Houd je machtigingen strak, je credentials veilig en veel plezier met coden!