Gedelegeerde versus toepassingsmachtigingen

By Mirko Peters · 2026-04-26 · Updated 2026-07-18

Vergelijk gedelegeerde en toepassingsmachtigingen in Microsoft Entra ID en kies het juiste toegangsmodel voor beveiligde API's, automatisering en app-ontwikkeling.

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

Als je met Microsoft Entra ID werkt, is uitzoeken wie wat mag doen, en onder welke omstandigheden, meer dan een technisch detail. Het is de ruggengraat van veilige app-ontwikkeling, automatisering en identity management in de cloud van Microsoft. Het verschil is groot tussen gebruikers toestaan om precies genoeg toegang te verlenen zodat je app namens hen kan handelen (gedelegeerde machtigingen), en een app de sleutels geven om zelfstandig dingen te doen (toepassingsmachtigingen).

Doe je dit verkeerd, dan kan dat deur openzetten voor ongewenste datablootstelling, compliance-problemen of zelfs beveiligingsincidenten. Doe je het goed, dan krijg je soepelere automatisering, duidelijker governance en tevreden auditors. Deze gids geeft je het volledige overzicht: de basis van deze machtigingstypen, hoe ze in de praktijk werken en alle beveiligings-, governance- en operationele aspecten die je nodig hebt om de slimste keuze voor jouw omgeving te maken. Laten we machtigingen op hun plek zetten, want met grote toegang komt serieuze verantwoordelijkheid.

Achtergrond en introductie van machtigingsmodellen in Microsoft Identity

Machtigingen in Microsoft Entra ID zijn niet zomaar vinkjes die je aanzet. Ze vormen een fundamenteel raamwerk dat is ingebouwd in de manier waarop apps en gebruikers samenwerken binnen Microsoft 365, Azure en daarbuiten. Toen Microsoft identity naar de cloud verplaatste, was er een manier nodig waarmee diensten en tools van derden veilig met elkaar konden communiceren, zonder dat iedereen en alles zomaar volledige toegang kreeg. Zo kwamen gedelegeerde en toepassingsmachtigingen tot stand.

Met deze modellen kun je precies beheren wie wat mag benaderen. Ze trekken duidelijke grenzen tussen wat een individuele gebruiker zelf kan goedkeuren en wat alleen een beheerder mag toestaan. Ze zijn het resultaat van jarenlang leren, soms de harde manier, van klassieke AD-serviceaccounts en onhandige alles-of-niets-toegang. Deze modellen begrijpen is niet alleen goede hygiëne. Het is essentieel om aan compliance-eisen te voldoen, Zero Trust af te dwingen en te voorkomen dat de dagelijkse werkzaamheden stilvallen door beveiligingsmisconfiguraties.

Toepassingsmachtigingen versus gedelegeerde machtigingen: kernconcepten en praktijkscenario's

Laten we het verschil tussen gedelegeerde en toepassingsmachtigingen in heldere taal uitleggen. Zie gedelegeerde machtigingen als je app die als hulp optreedt. Die krijgt alleen toegang terwijl een specifieke gebruiker is aangemeld, en is beperkt tot wat die gebruiker zelf zou mogen doen. Toepassingsmachtigingen laten je app daarentegen zelfstandig handelen, als een onbewaakte manager met zijn eigen sleutelbos. Er is helemaal geen gebruiker nodig om aanwezig te zijn.

Bij gedelegeerde machtigingen is altijd een gebruiker betrokken bij de authenticatie. Wanneer iemand zich aanmeldt, bijvoorbeeld bij een app die toegang nodig heeft tot zijn e-mail of agenda, geeft die persoon de app tijdelijk de ruimte om met zijn autoriteit te werken. Als de gebruiker zich afmeldt, sluit dat venster. Dit is ideaal voor apps die werk doen op verzoek van de gebruiker, zoals webfrontends, Teams-bots of mobiele productiviteitsapps.

Bij toepassingsmachtigingen authenticeert de app zichzelf als eigen identiteit (een service-principal) en krijgt hij een eigen token. Dit is wat automatisering en achtergrondtaken mogelijk maakt, zoals een systeemintegratie die 's nachts gegevens synchroniseert tussen SharePoint en je CRM. Er is geen gebruikersinteractie nodig. De app voert taken uit op zijn eigen schema en met zijn eigen toegangsniveau, beperkt tot wat een beheerder heeft goedgekeurd.

Stel dat je gebruikersprovisioning wilt automatiseren: een achtergrondservice die elke nacht rustig gebruikersaccounts bijwerkt. Dan zijn gedelegeerde machtigingen nutteloos, want er zit niemand klaar om toegang goed te keuren. Maar als je oplossing gepersonaliseerde functies moet bieden terwijl de gebruiker actief is, zoals een app voor het ondertekenen van documenten die aan OneDrive is gekoppeld, dan schitteren gedelegeerde machtigingen.

In echte scenario's is vaak een combinatie nodig. Daarom is het cruciaal om te weten welk model bij jouw use case past, voor gebruikerservaring, governance en beveiliging. Je wilt niet meer sleutels uitdelen dan nodig, maar je wilt ook niet dat je service om 03:00 uur 's nachts buiten de deur staat omdat er niemand is om zich aan te melden.

Gedelegeerde Entra-machtigingen in Microsoft: authenticatiestroom en beperkingen

Gedelegeerde machtigingen in Microsoft Entra ID leiden je door een klassieke, gebruikersgestuurde authenticatiestroom. Die begint wanneer een gebruiker zich aanmeldt bij je applicatie met zijn Microsoft-inloggegevens. Op dat moment vraagt de app om specifieke machtigingen (of scopes) en laat ze de gebruiker (en soms een beheerder) precies zien tot welke gegevens of acties ze toegang wil.

Als de gevraagde machtigingen alleen toestemming van de gebruiker vereisen, keurt die ze direct goed via een toestemmingsscherm. Voor gevoeligere machtigingen, zoals het lezen van de mailbox van iedereen in de organisatie, is toestemming van een beheerder nodig. Eenmaal goedgekeurd ontvangt je app een toegangstoken dat rechtstreeks is gekoppeld aan de identiteit van de gebruiker en de rollen die die is toegewezen.

Dat toegangstoken laat de app Microsoft Graph- of M365-API's aanroepen, maar de app handelt altijd met het gezag van de gebruiker. Als de gebruiker een gewone medewerker is, kan de app dus niet ineens beheerdersmogelijkheden gebruiken. Zodra de gebruiker zich afmeldt, droogt de toegang van de app op. Zo blijft de impact van een incident beperkt.

Maar er is een beperking: gedelegeerde machtigingen werken niet goed in onbeheerde scenario's. Als je een achtergrondproces, cronjob of serviceintegratie draait die niet afhankelijk mag zijn van iemand die actief inlogt, schieten gedelegeerde machtigingen tekort. Alles hangt dan af van de aanwezigheid van een gebruiker, dus ondersteuning, automatisering en nachtelijke taken lopen tegen een muur aan.

Er speelt ook een beveiligingsaspect mee. Als een gebruiker met brede toegang wordt misleid om toestemming te geven, kan een app die machtigingen misbruiken. Dat is een belangrijke aanvalsroute bij consent-phishing. Daarom heb je strakke controles nodig op wie welke machtigingen mag verlenen, en goede bewustwordingstraining over wat die toestemmingsschermen echt betekenen.

Te ruime toegang voor apps en tokenbeveiliging in Microsoft Entra ID

Als het om machtigingen gaat, is meer niet altijd beter. Te ruim toekennen, oftewel onnodige of overmatige rechten uitdelen, vooral bij applicatiemachtigingen, kan de deur openzetten voor datalekken en ernstige beveiligingsincidenten. Stel dat je een app lees- en schrijfrechten geeft op elke mailbox in het bedrijf, terwijl die alleen agenda-afspraken hoeft te lezen. Dan heb je je aanvalsoppervlak flink vergroot.

Dit gevaar is niet louter theoretisch. Aanvallers misbruiken OAuth-toestemmingen om zelfs multifactorauthenticatie te omzeilen. Ze richten zich op gebruikers of beheerders met slimme toestemmingsvragen en misleiden hen om riskante machtigingen goed te keuren. Eenmaal binnen houden die kwaadaardige apps vaak toegang, zelfs als wachtwoorden worden gewijzigd of MFA wordt afgedwongen. De greep van de aanvaller blijft bestaan, waardoor traditionele verdediging niet meer werkt. Voor een praktijkvoorbeeld kun je deze uitleg bekijken over hoe aanvallers OAuth-toestemming in Entra ID misbruiken, inclusief de beste manieren om dat af te sluiten.

Het verhaal stopt niet bij over-permissioning. Tokens en inloggegevens, ook clientgeheimen en certificaten, kunnen een goudmijn worden voor aanvallers als ze niet goed beveiligd zijn. Een gelekt clientgeheim van een app-only registratie is alles wat een aanvaller nodig heeft om je service na te bootsen. Daarom is hygiëne met inloggegevens essentieel: gebruik waar mogelijk beheerde identiteiten, roteer geheimen en bewaar clientgegevens nooit in code of in onbeveiligde bestanden. Voor omgevingen die afhankelijk zijn van niet-menselijke toegang is het zinvol om Microsoft Entra Workload Identities te overwegen. Die maken geheimloze, controleerbare toegang mogelijk en nemen de hoofdpijn van verouderde serviceaccounts weg. Hier vind je een diepere duik in waarom workload-identiteiten onmisbaar zijn voor Zero Trust.

Tot slot is goede monitoring onmisbaar. Controleer regelmatig de aanmeldingslogboeken en OAuth-toekenningen, stel waarschuwingen in voor verdachte toestemming of tokengebruik, en blijf een stap voor op consent-phishing en tokendiefstal. Bevindingen uit echte datalekken (zoals deze Microsoft 365-aanvalsketen) laten zien dat aanvallers zwakke governance uitbuiten, dus hoe meer zicht, hoe beter. Bescherm de sleutels, beperk de machtigingen en zorg dat je apps zich correct gedragen.

Beheersmaatregelen en best practices voor het beheren van gedelegeerde en applicatiemachtigingen

• Implementeer ingebouwde Entra-controles voor machtigingenbeheerGebruik de ingebouwde toestemmingsworkflows, goedkeuringsprocessen voor beheerders en fijnmazige beleidsregels van Microsoft Entra om te beperken welke gebruikers of groepen machtigingen mogen verlenen. Gebruik beleid voor beheerderstoestemming om ervoor te zorgen dat alleen gecontroleerde apps scopes met een hoog risico krijgen.
• Pas het principe van minimale rechten toeGeef apps alleen de minimale set machtigingen die nodig is voor hun functie. Controleer elke machtiging die tijdens de app-registratie wordt gevraagd en verwijder alles wat niet nodig is. Minimale rechten vormen je sterkste verdediging tegen misbruik en overmatige toegang.
• Plan regelmatige beoordelingen van machtigingen en auditsStel routinematige toegangsbeoordelingen in, met gebruik van de dashboards voor machtigingen en toestemmingen van Entra, om ongebruikte of riskante machtigingen op te sporen en in te trekken. Automatiseer deze controles waar mogelijk voor schaalbaar bestuur, zoals beschreven in geavanceerde governancegidsen zoals deze Microsoft Purview-strategie.
• Monitor en waarschuw bij wijzigingen in machtigingenRicht monitoring en waarschuwingen in om nieuwe OAuth-toekenningen, pieken in het gebruik van app-machtigingen of onverwachte integraties door beheerders op te sporen. Proactieve rapportage geeft je tijd om te reageren voordat beveiligingsproblemen escaleren.
• Beveilig de opslag van tokens en referentiesBewaar clientgeheimen en tokens in beveiligde kluizen zoals Azure Key Vault. Roteer referenties regelmatig, gebruik certificaten in plaats van gedeelde geheimen en geef de voorkeur aan workload-identiteiten bij niet-menselijke toegang, omdat die een beter levenscyclusbeheer en betere controleerbaarheid bieden.
• Adopteer geavanceerd governance- en beleidsautomatiseringMaak gebruik van tools zoals Microsoft Purview en Azure Policy om controles over de hele tenant af te dwingen, risico’s te segmenteren met Data Loss Prevention en ontwerp voor voortdurende compliance. Voor een praktische kijk op het gebruik van beleid voor governance by design, zie de Azure-strategie voor enterprise governance.

Door deze stappen te volgen en gebruik te maken van het ecosysteem van governancetools van Microsoft, zorg je ervoor dat je organisatie permissierisico’s beheert voordat ze problemen worden. Leer gebruikers regelmatig veilig omgaan met toestemmingen, automatiseer waar mogelijk en onthoud dat permissiebeheer nooit eenmalig is. Blijf alert, blijf beleid verfijnen, dan blijft je Entra ID-omgeving in goede conditie.

Luister ook naar deze afleveringen

Als je gedelegeerde versus applicatiemachtigingen in Entra ID verkent, geven deze afleveringen praktische context voor veilige adoptie van Microsoft 365, gegevensbescherming, governance en AI-risicobeheer.

• Microsoft Purview – Simply Explained — Ontdek hoe classificatie, bewaring, compliance en bescherming samenkomen in één Microsoft-model voor datagovernance.
• Microsoft Defender XDR – Simply Explained — Verbind gegevensbeschermingsmaatregelen met detectie, onderzoek en respons.
• Conditional Access – Simply Explained — Begrijp hoe identiteits- en risicosignalen context toevoegen aan toegangsbeslissingen.
• Microsoft AI Agent Harness – Simply Explained — Verken de controles die AI-automatisering betrouwbaarder, beter observeerbaar en veiliger maken.

Deze afleveringen helpen je de concepten uit het artikel om te zetten in praktische ontwerp- en uitrolbeslissingen.