Gedelegeerde en toepassingsmachtigingen in Microsoft Entra ID: wat beheerders moeten weten

By Mirko Peters · 2026-10-28

Ontdek de belangrijkste verschillen tussen gedelegeerde en toepassingsmachtigingen in Microsoft Entra ID, inclusief best practices voor beveiliging en de regels van least privilege.

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

Wanneer je externe tools of eigen applicaties koppelt aan je Microsoft 365-omgeving, is het begrijpen van het verschil tussen gedelegeerde en toepassingsmachtigingen essentieel voor het waarborgen van cloudbeveiliging, het voorkomen van datalekken en het toepassen van het least privilege-principe binnen Microsoft Entra ID.

Belangrijkste punten

• Gedelegeerde machtigingen vereisen een aangemelde gebruiker en handelen namens die gebruiker. De app kan dus alleen gegevens benaderen die de gebruiker mag zien.
• Toepassingsmachtigingen werken zonder menselijke gebruiker en geven brede toegang tot een hele tenant. Ze vereisen goedkeuring door een beheerder.
• Het least privilege-principe houdt in dat apps altijd de kleinst mogelijke set machtigingen krijgen die nodig is om hun taak uit te voeren.
• Microsoft Graph fungeert als de centrale toegangspoort tot Microsoft 365-gegevens en is sterk afhankelijk van deze machtigingsmodellen.
• Inzicht in het verschil voorkomt ernstige beveiligingslekken, zoals het per ongeluk verlenen van ongewenste tenantbrede toegang aan externe applicaties.

OAuth-machtigingen begrijpen in de Microsoft-cloud

Wanneer je een externe productiviteitstool of een interne automatiseringsscript koppelt aan je Microsoft 365-werkruimte, start je een onderliggend OAuth 2.0-proces. Een toegangstoken krijgen is echter maar het halve werk. De echte beveiligingsgrens wordt bepaald door wat dat token daadwerkelijk mag doen. Binnen het Microsoft-identiteitsecosysteem, met Microsoft Entra ID (voorheen Azure Active Directory) als basis, zijn machtigingen onderverdeeld in twee fundamenteel verschillende vormen: gedelegeerde machtigingen en toepassingsmachtigingen.

Deze twee modellen door elkaar halen is een van de meest voorkomende valkuilen voor IT-beheerders, ontwikkelaars en power users. Het kiezen van het verkeerde machtigingstype kan per ongeluk bedrijfsbrede gegevens blootstellen of de werking van een applicatie volledig verstoren. Laten we uitzoeken hoe elk type werkt, waar ze gedefinieerd staan en hoe je ze correct beheert.

Gedelegeerde machtigingen: handelen namens een gebruiker

Gedelegeerde machtigingen zijn bedoeld voor apps waarachter een menselijke gebruiker zit. Wanneer je je met je Microsoft-account aanmeldt bij een mobiele app of webservice, leent de app je identiteit voor een specifieke set taken. Dit wordt een gedelegeerde machtiging genoemd.

In dit scenario handelt de app als jij. Ze kan alleen bij gegevens komen waar jij al toegang toe hebt, en niets meer. Als je gebruikersaccount geen leesrechten heeft op een specifieke SharePoint-map of de agenda van een collega, dan heeft de app die ook niet. Omdat de impact van een fout beperkt blijft tot de machtigingen van de individuele gebruiker, raadt Microsoft aan om gedelegeerde machtigingen te gebruiken wanneer er een mens bij de workflow betrokken is.

Zo zien gedelegeerde machtigingen er in de praktijk uit

Je komt gedelegeerde machtigingen tegen elke keer dat je een toestemmingsvenster aanklikt. Een planningsassistent kan bijvoorbeeld een scherm tonen dat aangeeft dat hij je agenda wil lezen. Dat verzoek vertegenwoordigt een specifieke OAuth-scope. Omdat jij aanwezig bent om het verzoek goed te keuren of af te wijzen, handel je als resource-eigenaar en bepaal je precies wat de clienttoepassing van je profiel mag lenen.

Toepassingsmachtigingen: achtergrondservices en tenantbrede toegang

Toepassingsmachtigingen werken volgens een heel ander principe. Ze zijn bedoeld voor achtergrondprocessen, geautomatiseerde synchronisatiescripts en backendservices die om drie uur 's nachts draaien, wanneer er geen gebruiker is aangemeld. Denk aan een geautomatiseerde rapportagetool die gegevens verzamelt uit elke postbus in de organisatie.

Omdat er geen gebruiker aanwezig is om identiteitscontext te leveren, authenticeert de app zichzelf met zijn eigen referenties (zoals een client-ID en clientgeheim via de client credentials flow). Daardoor kunnen toepassingsmachtigingen de tool laten handelen namens zichzelf, binnen de hele organisatie. Als een app toepassingsmachtigingen heeft om e-mail te lezen, kan die de e-mail van elke gebruiker in de tenant lezen.

Waarom beheerderstoestemming verplicht is

Gezien de enorme macht die met toepassingsmachtigingen gepaard gaat, kunnen gewone gebruikers er niet mee instemmen. Een gewone medewerker kan een gedelegeerde machtiging voor de eigen agenda goedkeuren, maar toepassingsmachtigingen vereisen uitdrukkelijke goedkeuring van een globale beheerder of een beheerder met een bevoegde rol. Deze strenge controle voorkomt dat kwaadaardige of slecht geschreven apps stilletjes gegevens van de hele organisatie verzamelen.

Microsoft Graph en de rol van OAuth-scopes

Of een app nu gedelegeerde of toepassingsmachtigingen gebruikt, uiteindelijk stuurt hij alle verzoeken via één krachtige toegangspoort: Microsoft Graph. Elk teamsgesprek, elk SharePoint-document, elk OneDrive-bestand en elke Outlook-e-mail is bereikbaar via Microsoft Graph, zolang de aanroepende app een geldig OAuth-toegangstoken kan tonen.

De waarborgen die deze tokens betrouwbaar houden, heten scopes. Een scope is een precies label in het token dat de exacte grenzen vastlegt, zoals het lezen van een agenda of het versturen van een e-mail. Wanneer ontwikkelaars te brede scopes aanvragen (bijvoorbeeld lees- en schrijftoegang terwijl alleen leestoegang nodig is), schenden ze de kernprincipes van goede beveiliging. Beheerders moeten deze scopes zorgvuldig controleren bij het beoordelen van app-registraties.

Least privilege afdwingen in je tenant

Beveiligingsbest practices binnen Microsoft Entra ID komen altijd terug op één gouden regel: het principe van least privilege. Elke app, serviceprincipal en automatisering moet alleen het absolute minimum aan toegang krijgen dat nodig is om zijn taak uit te voeren.

• Geef altijd gedelegeerde machtigingen de voorkeur boven toepassingsmachtigingen wanneer een mens met de app werkt.
• Kijk kritisch naar toestemmingsvragen en controleer of apps niet om onnodige scopes vragen.
• Beoordeel regelmatig de bedrijfsapps die in Microsoft Entra ID zijn geregistreerd, om verweesde tokens of ongebruikte app-registraties in te trekken.
• Zorg voor beheerderstoezicht op elke client credentials flow die in headless omgevingen draait.

Conclusie

Wie de werking van moderne cloudidentiteit wil begrijpen, moet verder kijken dan de eenvoudige aanmeldknoppen en de onderliggende machtigingsstructuren onderzoeken. Of je nu gebruikersgerichte mobiele apps beheert met gedelegeerde scopes of zware enterpriseautomatisering met toepassingsmachtigingen, inzicht in deze grenzen is essentieel voor een veilige Microsoft 365-omgeving.

Wil je dieper ingaan op de basis van hoe deze handshakes werken? Luister de volledige aflevering van de podcast voor een uitleg zonder jargon over OAuth 2.0, tokenlevenscycli en de vier partijen in elke handshake.

Veelgestelde vragen

Kunnen gewone gebruikers toepassingsmachtigingen goedkeuren in Microsoft Entra ID?

Nee. Toepassingsmachtigingen werken zonder aangemelde gebruiker en hebben reikwijdte over de hele tenant. Daarom kan alleen een beheerder met de juiste tenantrechten toepassingsmachtigingen verlenen.

Wat gebeurt er als een gebruiker via een app met gedelegeerde machtigingen toegang probeert te krijgen tot een bestand waarvoor hij geen rechten heeft?

De app krijgt dan ook geen toegang tot dat bestand. Gedelegeerde machtigingen lenen de identiteit van de gebruiker, waardoor de app nooit verder kan gaan dan de persoonlijke toegangsgrenzen van die gebruiker.

Wat is het belangrijkste beveiligingsrisico van toepassingsmachtigingen?

Omdat toepassingsmachtigingen achtergronddiensten laten draaien zonder menselijk toezicht, kan een gecompromitteerde app-referentie een aanvaller onbeperkte toegang geven tot postbussen, bestanden en andere bronnen van het bedrijf.

Hoe werkt Microsoft Graph samen met OAuth-tokens en machtigingen?

Microsoft Graph fungeert als de API-gateway voor Microsoft 365. Elke aanvraag aan Graph moet een OAuth-toegangstoken bevatten dat specifieke bereiken insluit, die bepalen of er gedelegeerde machtigingen of toepassingsmachtigingen gelden.