Overzicht van machtigingen en toestemming in het Microsoft Identity Platform
In het Microsoft Identity Platform is het belangrijk om machtigingen en toestemming te begrijpen voor het ontwikkelen van beveiligde toepassingen waarvoor toegang tot beveiligde resources is vereist. Dit artikel bevat een overzicht van de basisconcepten en scenario's met betrekking tot machtigingen en toestemming, zodat toepassingsontwikkelaars de benodigde autorisaties aanvragen van gebruikers en beheerders. Door deze concepten te begrijpen, kunt u ervoor zorgen dat uw toepassingen alleen de toegang aanvragen die ze nodig hebben, en vertrouwen en beveiliging bevorderen.
Voor toegang tot een beveiligde resource, zoals e-mail- of agendagegevens, heeft uw toepassing de autorisatie van de resource-eigenaar nodig. De resource-eigenaar kan uw app-aanvraag goedkeuren of weigeren. Als u deze basisconcepten begrijpt, kunt u veiligere en betrouwbare toepassingen bouwen die alleen de toegang aanvragen die ze nodig hebben, wanneer ze deze nodig hebben, van gebruikers en beheerders.
Toegangsscenario's
Als toepassingsontwikkelaar moet u bepalen hoe uw toepassing toegang heeft tot gegevens. De toepassing kan gedelegeerde toegang gebruiken, handelen namens een aangemelde gebruiker of alleen-app-toegang, die alleen fungeert als de eigen identiteit van de toepassing.
Gedelegeerde toegang (toegang namens een gebruiker)
In dit toegangsscenario heeft een gebruiker zich aangemeld bij een clienttoepassing. De clienttoepassing heeft namens de gebruiker toegang tot de resource. Gedelegeerde toegang vereist gedelegeerde machtigingen. Zowel de client als de gebruiker moeten afzonderlijk worden geautoriseerd om de aanvraag te kunnen indienen. Zie het scenario voor gedelegeerde toegang voor meer informatie over het scenario voor gedelegeerde toegang.
Voor de client-app moeten de juiste gedelegeerde machtigingen worden verleend. Gedelegeerde machtigingen kunnen ook scopes worden genoemd. Scopes zijn machtigingen voor een bepaalde bron, die aangeven waartoe een clienttoepassing namens de gebruiker toegang kan krijgen. Voor meer informatie over bereiken, zie bereiken en machtigingen.
Voor de gebruiker is de autorisatie afhankelijk van de bevoegdheden die de gebruiker krijgt om toegang te krijgen tot de resource. De gebruiker kan bijvoorbeeld worden geautoriseerd voor toegang tot adreslijstbronnen door op rollen gebaseerd toegangsbeheer (RBAC) van Microsoft Entra of om toegang te krijgen tot e-mail- en agendabronnen door Exchange Online RBAC. Zie RBAC voor toepassingenvoor meer informatie over RBAC voor toepassingen.
Alleen-app-toegang (toegang zonder een gebruiker)
In dit toegangsscenario fungeert de toepassing zelfstandig zonder dat er een gebruiker is aangemeld. Toepassingstoegang wordt gebruikt in scenario's zoals automatisering en back-up. Dit scenario omvat apps die worden uitgevoerd als achtergrondservices of daemons. Het is van toepassing wanneer het niet wenselijk is om een specifieke gebruiker aan te laten aanmelden of wanneer de vereiste gegevens niet kunnen worden beperkt tot één gebruiker. Zie app-only-accessvoor meer informatie over het scenario voor alleen-app-toegang.
Alleen-app-toegang maakt gebruik van app-rollen in plaats van gedelegeerde bevoegdheden. Wanneer toestemming wordt verleend, kunnen app-rollen ook wel toepassingsmachtigingen worden genoemd. De client-app moet de juiste toepassingsmachtigingen krijgen van de resource-app die wordt aangeroepen. Zodra deze is verleend, heeft de client-app toegang tot de aangevraagde gegevens. Zie App-rollen toewijzen aan toepassingen voor meer informatie over het toewijzen van app-rollen aan clienttoepassingen.
Typen permissies
Gedelegeerde machtigingen worden gebruikt in het scenario voor gedelegeerde toegang. Dit zijn machtigingen waarmee de toepassing in naam van een gebruiker kan handelen. De toepassing heeft geen toegang tot iets wat de aangemelde gebruiker niet kan openen.
Neem bijvoorbeeld een toepassing waaraan de Files.Read.All gedelegeerde machtiging is verleend namens de gebruiker. De toepassing kan alleen bestanden lezen waartoe de gebruiker persoonlijk toegang heeft.
Toepassingsmachtigingen, ook wel app-rollen genoemd, worden gebruikt in het scenario voor alleen-app-toegang, zonder dat er een aangemelde gebruiker aanwezig is. De toepassing heeft toegang tot alle gegevens waaraan de machtiging is gekoppeld.
Een toepassing die de toepassingsmachtiging Files.Read.All van de Microsoft Graph API heeft gekregen, kan met behulp van Microsoft Graph elk bestand in de tenant lezen. Over het algemeen kan alleen een beheerder of eigenaar van de service-principal van een API toestemming geven voor toepassingsmachtigingen die door die API worden weergegeven.
Vergelijking van gedelegeerde machtigingen en toepassingsmachtigingen
| Machtigingstypen | Gedelegeerde machtigingen | Toepassingsmachtigingen |
|---|---|---|
| Typen apps | Web/Mobiel/single-page app (SPA) | Web / Daemon |
| Toegangscontext | Toegang krijgen namens een gebruiker | Toegang krijgen zonder een gebruiker |
| Wie kan toestemming verlenen? | - Gebruikers kunnen toestemming geven voor hun gegevens - Beheerders kunnen toestemming geven voor alle gebruikers |
Alleen de beheerder kan toestemming geven |
| Toestemmingsmethoden | - Statisch: geconfigureerde lijst bij app-registratie - Dynamisch: afzonderlijke machtigingen aanvragen bij aanmelden |
- Alleen statische: geconfigureerde lijst bij app-registratie |
| Overige namen | -Scopes - OAuth2-machtigingsbereiken |
- App-rollen - Machtigingen voor alleen apps |
| Resultaat van toestemming (specifiek voor Microsoft Graph) | OAuth2PermissionGrant | appRoleAssignment |
Toestemming
Een manier waarop toepassingen machtigingen krijgen, is via toestemming. Toestemming is een proces waarbij gebruikers of beheerders een toepassing machtigen voor toegang tot een beveiligde resource. Wanneer een gebruiker zich bijvoorbeeld voor het eerst probeert aan te melden bij een toepassing, kan de toepassing toestemming vragen om het profiel van de gebruiker te zien en de inhoud van het postvak van de gebruiker te lezen. De gebruiker ziet de lijst met machtigingen die de app aanvraagt via een toestemmingsprompt. Andere scenario's waarin gebruikers een toestemmingsprompt kunnen zien, zijn onder andere:
- Wanneer eerder toestemming is verleend, wordt deze ingetrokken.
- Wanneer de toepassing is gecodeerd om specifiek om toestemming te vragen tijdens het aanmelden.
- Wanneer de toepassing dynamische toestemming gebruikt om zo nodig om nieuwe machtigingen te vragen.
De belangrijkste details van een toestemmingsprompt zijn de lijst met machtigingen die de toepassing vereist en de informatie van de uitgever. Zie toepassingstoestemmingservaringvoor meer informatie over de toestemmingsprompt en de toestemmingservaring voor zowel beheerders als eindgebruikers.
Gebruikerstoestemming
Gebruikerstoestemming vindt plaats wanneer een gebruiker zich probeert aan te melden bij een toepassing. De gebruiker verstrekt zijn aanmeldingsreferenties, die worden gecontroleerd om te bepalen of er al toestemming is verleend. Als er geen vorige record van gebruikers- of beheerderstoestemming voor de vereiste machtigingen bestaat, wordt de gebruiker een toestemmingsprompt weergegeven en wordt gevraagd de toepassing de aangevraagde machtigingen te verlenen. Een beheerder moet mogelijk toestemming verlenen namens de gebruiker.
Beheerderstoestemming
Afhankelijk van de machtigingen die ze nodig hebben, is voor sommige toepassingen mogelijk een beheerder vereist die toestemming verleent. Toepassingsmachtigingen en veel gedelegeerde machtigingen met hoge bevoegdheden kunnen bijvoorbeeld alleen worden toegestaan door een beheerder.
Beheerders kunnen toestemming voor zichzelf of voor de hele organisatie verlenen. Zie het overzicht van gebruikers- en beheerderstoestemming voor meer informatie over toestemming van gebruikers en beheerders.
Verificatieaanvragen vereisen beheerderstoestemming als er geen toestemming is verleend en een van deze machtigingen met hoge bevoegdheid wordt aangevraagd.
Machtigingsaanvragen die aangepaste toepassingsbereiken bevatten, worden niet beschouwd als hoge bevoegdheden en daarom hebben ze geen beheerderstoestemming nodig.
Verificatie vooraf
Met preauthorization kan een eigenaar van een resourcetoepassing machtigingen verlenen zonder dat gebruikers een toestemmingsprompt moeten zien voor dezelfde set machtigingen die vooraf zijn geverifieerd. Op deze manier vraagt een vooraf geverifieerde toepassing gebruikers niet om toestemming te geven voor machtigingen. Resource-eigenaren kunnen client-apps vooraf verifiëren in Azure Portal of met behulp van PowerShell en API's zoals Microsoft Graph.
Andere autorisatiesystemen
Het toestemmingsframework is slechts één manier waarop een toepassing of gebruiker kan worden geautoriseerd voor toegang tot beveiligde resources. Beheerders moeten zich bewust zijn van andere autorisatiesystemen die toegang kunnen verlenen tot gevoelige informatie. Voorbeelden van verschillende autorisatiesystemen bij Microsoft zijn ingebouwde rollen van Microsoft Entra, Azure RBAC-, Exchange RBAC-en Teams-resourcespecifieke toestemming.