Machtigingen en toestemming detecteren

  • 3 minuten

Toepassingen die zijn geïntegreerd met het Microsoft Identity-platform volgen een autorisatiemodel dat gebruikers en beheerders controle geeft over de toegang tot gegevens.

Het Microsoft Identity Platform implementeert het OAuth 2.0-autorisatieprotocol. OAuth 2.0 is een methode waarmee een app van derden namens een gebruiker toegang heeft tot door het web gehoste resources. Elke door het web gehoste resource die kan worden geïntegreerd met het Microsoft Identity Platform heeft een resource-id of toepassings-id-URI.

Hier volgen enkele voorbeelden van Microsoft door web gehoste resources:

  • Microsoft Graph: https://graph.microsoft.com
  • Microsoft 365 Mail API: https://outlook.office.com
  • Azure Key Vault: https://vault.azure.net

Hetzelfde geldt voor alle resources van derden die zijn geïntegreerd met het Microsoft Identity Platform. Elk van deze resources kan ook een set machtigingen definiëren die kunnen worden gebruikt om de functionaliteit van die resource te verdelen in kleinere segmenten. Wanneer de functionaliteit van een resource is onderverdeeld in kleine machtigingensets, kunnen apps van derden worden gebouwd om alleen de machtigingen aan te vragen die ze nodig hebben om hun functie uit te voeren. Gebruikers en beheerders kunnen weten tot welke gegevens de app toegang heeft.

In OAuth 2.0 worden deze typen machtigingensets bereiken genoemd. Ze worden ook wel machtigingen genoemd. In het Microsoft Identity Platform wordt een machtiging weergegeven als een tekenreekswaarde. Een app vraagt de benodigde machtigingen aan door de machtiging op te geven in de scope-queryparameter. Identiteitsplatform ondersteunt verschillende goed gedefinieerde OpenID Connect-bereiken en op resources gebaseerde machtigingen (elke machtiging wordt aangegeven door de machtigingswaarde toe te voegen aan de id of toepassings-id-URI van de resource). De machtigingstekenreeks https://graph.microsoft.com/Calendars.Read wordt bijvoorbeeld gebruikt om toestemming te vragen voor het lezen van agenda's van gebruikers in Microsoft Graph.

Een app vraagt deze machtigingen meestal aan door de bereiken op te geven in aanvragen voor het Microsoft Identity Platform-autorisatie-eindpunt. Sommige machtigingen met hoge bevoegdheden kunnen echter alleen worden verleend via beheerderstoestemming. Ze kunnen worden aangevraagd of toegekend met behulp van het eindpunt voor beheerderstoestemming.

Notitie

Bij aanvragen voor de autorisatie-, token- of toestemmingseindpunten voor het Microsoft Identity Platform, als de resource-id wordt weggelaten in de bereikparameter, wordt ervan uitgegaan dat de resource Microsoft Graph is. scope=User.Read is bijvoorbeeld gelijk aan https://graph.microsoft.com/User.Read.

Machtigingstypen

Het Microsoft Identity Platform ondersteunt twee typen machtigingen: gedelegeerde toegang en alleen-app-toegang.

  • Gedelegeerde toegang wordt gebruikt door apps die een aangemelde gebruiker hebben. Voor deze apps geeft de gebruiker of beheerder toestemming voor de machtigingen die de app aanvraagt. De app wordt gedelegeerd met de machtiging om te fungeren als een aangemelde gebruiker wanneer deze de doelresource aanroept.

  • Machtigingen voor alleen-app-toegang worden gebruikt door apps die worden uitgevoerd zonder een aangemelde gebruiker, bijvoorbeeld apps die worden uitgevoerd als achtergrondservices of daemons. Alleen een beheerder kan toestemming geven voor toegangsmachtigingen voor apps.

Toepassingen in Microsoft Identity Platform zijn afhankelijk van toestemming om toegang te krijgen tot benodigde resources of API's. Er zijn veel soorten toestemming waarover uw app mogelijk moet weten om succesvol te zijn. Als u machtigingen definieert, moet u ook begrijpen hoe uw gebruikers toegang krijgen tot uw app of API.

Er zijn drie toestemmingstypen: statische gebruikerstoestemming, incrementele en dynamische gebruikerstoestemming en beheerderstoestemming.

In het scenario met statische gebruikerstoestemming moet u alle benodigde machtigingen hebben opgegeven in de configuratie van de app in de Azure Portal. Als de gebruiker (of beheerder, indien van toepassing) geen toestemming heeft verleend voor deze app, vraagt Het Microsoft Identity Platform de gebruiker op dit moment toestemming te geven. Met statische machtigingen kunnen beheerders ook toestemming geven namens alle gebruikers in de organisatie.

Hoewel statische machtigingen van de app die in de Azure Portal de code mooi en eenvoudig houden, worden er enkele mogelijke problemen voor ontwikkelaars weergegeven:

  • De app moet alle machtigingen aanvragen die nodig zijn voor de eerste aanmelding van de gebruiker. Dit kan leiden tot een lange lijst met machtigingen waarmee eindgebruikers de toegang van de app bij de eerste aanmelding kunnen goedkeuren.

  • De app moet alle resources kennen die deze ooit eerder zou openen. Het is moeilijk om apps te maken die toegang hebben tot een willekeurig aantal resources.

Met het Microsoft Identity Platform-eindpunt kunt u de statische machtigingen negeren die zijn gedefinieerd in de app-registratiegegevens in de Azure Portal en in plaats daarvan incrementeel machtigingen aanvragen. U kunt vooraf om een minimale set machtigingen vragen en meer aanvragen wanneer de klant meer app-functies gebruikt.

Hiervoor kunt u op elk gewenst moment de bereiken opgeven die uw app nodig heeft door de nieuwe bereiken in de parameter op te slaan bij het scope aanvragen van een toegangstoken, zonder dat u ze vooraf hoeft te bepalen in de registratiegegevens van de toepassing. Als de gebruiker nog geen toestemming heeft gegeven voor nieuwe bereiken die aan de aanvraag zijn toegevoegd, wordt de gebruiker gevraagd om alleen toestemming te geven voor de nieuwe machtigingen. Incrementele of dynamische toestemming is alleen van toepassing op gedelegeerde machtigingen en niet op machtigingen voor alleen-app-toegang.

Belangrijk

Dynamische toestemming kan handig zijn, maar brengt een grote uitdaging met zich mee voor machtigingen die toestemming van een beheerder vereisen omdat de toestemmingservaring van de beheerder op het moment van toestemming niets weet over deze machtigingen. Als u beheerdersmachtigingen nodig hebt of als uw app dynamische toestemming gebruikt, moet u alle machtigingen registreren in Azure Portal (niet alleen de subset van machtigingen waarvoor beheerderstoestemming is vereist). Hierdoor kunnen tenantbeheerders namens alle gebruikers toestemming geven.

Toestemming van de beheerder - Is vereist als uw app toegang nodig heeft tot bepaalde machtigingen met hoge privileges. Beheerderstoestemming zorgt ervoor dat beheerders andere besturingselementen hebben voordat ze apps of gebruikers machtigen om toegang te krijgen tot gegevens met hoge bevoegdheden van de organisatie.

Beheerderstoestemming die namens een organisatie wordt uitgevoerd, vereist nog steeds de statische machtigingen die zijn geregistreerd voor de app. Stel deze machtigingen voor apps in de app-registratieportal in als een beheerder namens de hele organisatie toestemming moet geven. Dit vermindert de cycli die de organisatiebeheerder nodig heeft om de toepassing in te stellen.

In een OpenID Connect- of OAuth 2.0-autorisatieaanvraag kan een app de benodigde machtigingen aanvragen met behulp van de bereikqueryparameter. Wanneer een gebruiker zich bijvoorbeeld aanmeldt bij een app, verzendt de app een aanvraag zoals in het volgende voorbeeld. Regeleinden worden toegevoegd voor leesbaarheid.

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=
https%3A%2F%2Fgraph.microsoft.com%2Fcalendars.read%20
https%3A%2F%2Fgraph.microsoft.com%2Fmail.send
&state=12345

De scope-parameter is een door spaties gescheiden lijst met gedelegeerde machtigingen die de app aanvraagt. Elke machtiging wordt aangegeven door de machtigingswaarde toe te voegen aan de id van de resource (de URI van de toepassings-id). In het aanvraagvoorbeeld heeft de app toestemming nodig om de agenda van de gebruiker te lezen en e-mail te verzenden als de gebruiker.

Nadat de gebruiker zijn referenties heeft ingevoerd, controleert het Microsoft Identity Platform op een overeenkomende record met gebruikerstoestemming. Als de gebruiker geen toestemming heeft gegeven voor een van de aangevraagde machtigingen in het verleden en als de beheerder niet namens de hele organisatie toestemming heeft gegeven voor deze machtigingen, vraagt het Microsoft Identity Platform de gebruiker om de aangevraagde machtigingen toe te kennen.