Overzicht van machtigingen en toestemming in het Microsoft Identity Platform
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 toestemming geven voor of weigeren van de aanvraag van uw app. Als u deze basisconcepten begrijpt, kunt u veiligere en betrouwbare toepassingen bouwen die alleen de toegang aanvragen die ze nodig hebben, wanneer ze het nodig hebben, van gebruikers en beheerders.
Toegangsscenario's
Als toepassingsontwikkelaar moet u bepalen hoe uw toepassing toegang krijgt 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 worden aangeduid als bereiken. Bereiken zijn machtigingen voor een bepaalde resource die aangeeft waartoe een clienttoepassing namens de gebruiker toegang heeft. Zie bereiken en machtigingen voor meer informatie over bereiken.
Voor de gebruiker is de autorisatie afhankelijk van de bevoegdheden die de gebruiker heeft gekregen voor toegang 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 toepassingen voor 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 Alleen-app-toegang voor meer informatie over het scenario voor alleen-app-toegang.
Alleen-app-toegang maakt gebruik van app-rollen in plaats van gedelegeerde bereiken. 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 machtigingen
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 nooit toegang tot alles wat de aangemelde gebruiker zelf niet kan openen.
Neem bijvoorbeeld een toepassing waaraan namens de gebruiker de Files.Read.All gedelegeerde machtiging is verleend. 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 verleend, kan bijvoorbeeld elk bestand in de tenant lezen met behulp van Microsoft Graph. 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/app met één pagina (BEVEILIGD-WACHTWOORDVERIFICATIE) | 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 aanmelding |
- 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 toevoegen | 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 mogelijk een toestemmingsprompt 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 de ervaring voor toepassingstoestemming voor 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 geeft de aanmeldingsreferenties op, 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 kan namens de gebruiker toestemming moeten verlenen.
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 worden gevraagd om beheerderstoestemming als er geen toestemming is verleend en of een van deze machtigingen met hoge bevoegdheden wordt aangevraagd.
Machtigingsaanvragen die aangepaste toepassingsbereiken bevatten, worden niet beschouwd als hoge bevoegdheden en daarom hebben ze geen beheerderstoestemming nodig.
Verificatie vooraf
Met verificatie vooraf kan een eigenaar van een resourcetoepassing machtigingen verlenen zonder dat gebruikers een toestemmingsprompt hoeven te zien voor dezelfde set machtigingen die vooraf zijn geverifieerd. Op deze manier vraagt een toepassing die vooraf is geverifieerd, 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 entra-rollen, Azure RBAC, Exchange RBAC en resourcespecifieke toestemming van Teams.