Toepassingen, resources en workloads autoriseren met Microsoft Entra-id

In dit artikel bespreken we autorisatie wanneer een individuele persoon communiceert met een toepassing en een toepassing leidt, wanneer Application Programming Interfaces (API) voor een gebruiker handelen. We bespreken ook wanneer toepassingen of services onafhankelijk werken. Het is de vierde in een reeks artikelen over hoe onafhankelijke softwareontwikkelaars (ISV's) hun toepassingen voor Microsoft Entra ID kunnen bouwen en optimaliseren. In deze reeks vindt u meer informatie over deze onderwerpen:

Autorisatie in toepassingen

In deze sectie behandelen we scenario's waarin een persoon communiceert met en een toepassing doorsturen. In de sectie Autorisatie in resources (API's) wordt beschreven hoe API's autorisatie uitvoeren wanneer de gebruiker autorisatie nodig heeft voor toegang tot een resource, maar Microsoft Entra ID voert de uiteindelijke autorisatie niet uit. In de sectie Autorisatie in workloads worden scenario's behandeld waarin toepassingen of services onafhankelijk van elkaar werken.

Voor toepassingen zijn de volgende autorisaties vereist wanneer ze toegang nodig hebben tot resources voor een gebruiker.

  • De toepassing moet zijn gemachtigd om toegang te krijgen tot specifieke bewerkingen binnen specifieke resources voor de huidige gebruiker.
  • De gebruiker moet gemachtigd zijn om toegang te krijgen tot een resource onder de huidige voorwaarden.
  • De gebruiker moet gemachtigd zijn om toegang te krijgen tot een resource.

Het autorisatieproces begint met een toepassing die OAuth 2.0 gebruikt om een toegangstoken van Microsoft Entra-id aan te vragen voor toegang tot specifieke bewerkingen binnen een specifieke resource voor de gebruiker. In gedelegeerde toegang fungeert een app als gemachtigde voor de gebruiker.

Voor ontwikkelaars kan een resource een API zijn, zoals Microsoft Graph, Azure Storage of hun eigen API. De meeste API's hebben echter verschillende bewerkingen, zoals lezen en schrijven. Wanneer een toepassing alleen leest vanuit een API, mag een app alleen autorisatie hebben voor leesbewerkingen. Deze aanpak beschermt een toepassing tegen inbreuk en gebruik voor meer toegang dan de ontwikkelaar had bedoeld. De ontwikkelaar volgt het principe van minimale bevoegdheden wanneer de toepassing alleen autoriseert voor de bewerkingen die hiervoor zijn vereist.

Ontwikkelaars gebruiken de bereikparameter van een OAuth 2.0-aanvraag om aan te geven welke specifieke bewerkingen in een specifieke API nodig zijn. De API-ontwerper publiceert de toegangsbereiken die een applicatie als onderdeel van de API-app-registratie kan aanvragen. Microsoft Power BI-serviceomvangen bijvoorbeeld het volgende.

Power BI-service bereik Bedrijfsactiviteiten
https://analysis.windows.net/powerbi/api/Capacity.Read.All De app kan alle capaciteiten van Power BI Premium en Power BI Embedded bekijken waartoe de aangemelde gebruiker toegang heeft.
https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All De app kan alle capaciteiten van Power BI Premium en Power BI Embedded bekijken en bewerken waartoe de aangemelde gebruiker toegang heeft.

Als een toepassing alleen capaciteiten leest, vraagt de app het https://analysis.windows.net/powerbi/api/Capacity.Read.All bereik aan. Als een toepassing capaciteit bewerkt, vraagt de app het https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All bereik aan.

Het bereik bevat de identiteit van de API en de identiteit van de bewerking. In het https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All-bereik is de https://analysis.windows.net/powerbi/api-API. De bewerking is Capacity.ReadWrite.All. Gezien het brede bereik en de populariteit van de Microsoft Graph API kunnen ontwikkelaars scopes aanvragen voor Microsoft Graph zonder het API-component van de scope. Microsoft Graph definieert bijvoorbeeld een bereik van https://graph.microsoft.com/Files.Read die toepassingen kunnen aanvragen met Files.Read in plaats van de volledige bereiknaam te gebruiken.

Als u de eerste autorisatie wilt voltooien, moet een toepassing beschikken over autorisatie voor toegang tot specifieke bewerkingen binnen specifieke resources voor de huidige gebruiker. Microsoft Entra-id moet eerst de huidige gebruiker verifiëren. Eenmalige aanmelding (SSO) kan voldoen aan deze verificatie of vereist mogelijk een nieuwe gebruikersinteractie.

Nadat de Microsoft Entra-id de gebruiker heeft bepaald, wordt gecontroleerd of de gebruiker de toepassing heeft geautoriseerd voor het aangevraagde bereik. Dit proces wordt het verlenen van toestemming genoemd. Als de gebruiker toestemming heeft verleend, kan het autorisatieproces worden voortgezet. Met beheerderstoestemming kunnen beheerdersgebruikers toestemming geven voor zichzelf en voor de hele organisatie. Microsoft Entra ID controleert of de applicatie beheerderstoestemming heeft voor een scope. Indien verleend, wordt het autorisatieproces voortgezet.

Tijdens het ontwerp van het bereik kan een API-ontwerper bereiken aanwijzen waarvoor alleen een beheerder toestemming kan geven. Bereiken waarvoor beheerderstoestemming is vereist, vertegenwoordigen bewerkingen die de API-ontwerper als gevoeliger, krachtig of ruim implicerend genoeg beschouwt dat een niet-beheerder niet de bevoegdheid mag hebben om aan een toepassing te verlenen.

Hoewel API-ontwerpers de eerste zeg hebben in welke van hun scopes beheerdersgoedkeuring vereisen, hebben ze niet het laatste woord. Wanneer een API-ontwerper aanwijst dat voor een bereik beheerderstoestemming is vereist, is voor het bereik altijd beheerderstoestemming vereist. Voor scopes die de API-ontwerper niet aangeeft als vereist voor beheerderstoestemming, kan de tenantbeheerder beheerderstoestemming vereisen of kan op risico gebaseerde stapsgewijze toestemming bepalen of beheerderstoestemming vereist is. Ontwikkelaars kunnen niet voorspellen of een tokenaanvraag beheerderstoestemming vereist. Deze beperking heeft echter geen invloed op de code die nodig is. Toestemmingsontkenning is slechts een van de vele redenen voor weigering van tokenaanvragen. Toepassingen moeten altijd gracieus omgaan met het niet ontvangen van een token.

Als de gebruiker of de beheerder geen toestemming heeft verleend, ziet de gebruiker een toestemmingsprompt , zoals wordt weergegeven in het volgende voorbeeld.

Schermopname van de gebruikerstoestemmingsprompt.

Beheerderstoestemmingsprompts kunnen hen toestaan om toestemming namens uw organisatie te verlenen voor alle gebruikers in de tenant, zoals getoond in het volgende voorbeeld.

Schermopname van de prompt voor beheerderstoestemming.

Toepassingen bepalen de timing van gebruikerstoestemmingsprompts. Microsoft Entra ID ondersteunt statische toestemming: wanneer een toepassing het .default bereik gebruikt, vraagt de app alle machtigingen aan die zijn gedeclareerd in de registratie van de app. Met statische toestemming vraagt uw app vooraf alle machtigingen die deze mogelijk nodig heeft.

Statische toestemming kan gebruikers en beheerders ontmoedigen om de toegangsaanvraag van uw app goed te keuren. De best practice voor het aanvragen van toestemmingen is om bij het opstarten van uw toepassing de vereiste machtigingen dynamisch aan te vragen voor de basale functionaliteit in uw toepassing en om indien nodig meer bereiken aan te vragen. Vraag incrementeel meer bereiken aan wanneer de toepassing bewerkingen uitvoert waarvoor deze bereiken zijn vereist. Deze benadering biedt de gebruiker een beter inzicht in andere machtigingen die correleren met de timing van functionaliteit. Voor elk API-toegangstoken bevat Microsoft Entra ID alle machtigingen die eerder aan een toepassing zijn verleend en niet alleen de machtigingen in het verzoek.

Een toepassing kan bijvoorbeeld aanvragen om zich aan te melden bij de gebruiker en toegang te krijgen https://graph.microsoft.com/user.read tot het profiel van de gebruiker wanneer de toepassing wordt gestart. Later selecteert een gebruiker Opslaan in OneDrive en de toepassing vraagt https://graph.microsoft.com/files.readwrite om een bestand naar OneDrive van de gebruiker te schrijven. Omdat de gebruiker ziet waarom een app vraagt om naar oneDrive te schrijven, verleent de gebruiker de machtiging en slaat de app een bestand op in OneDrive van de gebruiker. De gebruiker sluit vervolgens de app. De volgende keer dat de app wordt gestart, vraagt deze https://graph.microsoft.com/user.read aan. Microsoft Entra ID retourneert een toegangstoken met https://graph.microsoft.com/user.read en https://graph.microsoft.com/files.readwrite scopes. Voor een tokenaanvraag voor het https://graph.microsoft.com/files.readwrite bereik is geen toestemming vereist omdat de gebruiker deze heeft verleend. Tokencaching in Microsoft Authentication Libraries (MSAL) verwerkt automatisch cachingtokens op basis van de verleende machtigingen. In dit voorbeeld wordt, nadat de app opnieuw is opgestart, MSAL aangeroepen om een token te verkrijgen met het https://graph.microsoft.com/files.readwrite bereik, waarbij het in de cache opgeslagen token van de eerste aanvraag van de app voor het https://graph.microsoft.com/user.read bereik wordt geretourneerd. Een andere aanroep van Microsoft Entra ID is overbodig.

Dynamische en incrementele toestemming vereisen geen gedeclareerde machtigingen tijdens de registratie van de toepassing. We raden echter ten zeerste aan dat toepassingen machtigingen declareren die een toepassing kan vereisen in een app-registratie om statische toestemming te ondersteunen. Beheerders kunnen beheerderstoestemming verlenen in het Microsoft Entra-beheercentrum, met behulp van Microsoft Graph PowerShell of met de Microsoft Graph API.

Als u beheerderstoestemming wilt verlenen voor een toepassing, gebruikt het Microsoft Entra-beheercentrum statische toestemming door toestemming aan te vragen met het .default bereik voor een app. Beheerders kunnen geen beheerderstoestemming verlenen in het Microsoft Entra-beheercentrum aan apps waarvoor toestemming is vereist als ontwikkelaars ze niet declareren in app-registratie.

Microsoft Entra ID-klanten kunnen beleid voor voorwaardelijke toegang gebruiken om resources (API's) en browsertoepassingen te beveiligen. Beheerders kunnen standaard geen beleid voor voorwaardelijke toegang toepassen op systeemeigen app-verificaties. Tenantbeheerders kunnen zich richten op alle resources (voorheen 'Alle cloud-apps') of aangepaste beveiligingskenmerken gebruiken om systeemeigen apps te targeten met beleid voor voorwaardelijke toegang. Zelfs als dit niet het doel is, bevat het afdwingen van beleid geen apps die toegang hebben tot Microsoft Graph of Azure AD Graph.

Toepassingen vereisen meestal geen speciale code voor voorwaardelijke toegang, tenzij de volgende scenario's van toepassing zijn.

  • Apps die de on-behalf-of-flow uitvoeren
  • Apps die toegang hebben tot meerdere services of resources
  • Apps met één pagina die gebruikmaken van MSAL.js
  • Web-apps die een resource aanroepen

Als uw app een van deze scenario's implementeert, raadpleegt u de richtlijnen voor ontwikkelaars voor voorwaardelijke toegang van Microsoft Entra.

Gratis Microsoft Entra ID-tenants kunnen geen gebruik maken van voorwaardelijke toegang (zie licentievereisten. De productietenant van uw bedrijf heeft mogelijk de vereiste licentie. Evalueer deze voorwaarden voordat u uw productietenant gebruikt voor testen. Er zijn richtlijnen voor het maken van een testtenant.

Het beleid voor voorwaardelijke toegang is standaard van toepassing op toepassingen en de resources die een app op app-niveau opent. IT-beheerders kunnen beleid op app-niveau toepassen op elke app zonder deelname aan ontwikkelaars. Voor sommige toepassingen en scenario's is meer granulariteit vereist. Een financiële app kan bijvoorbeeld meervoudige verificatie vereisen voor normaal gebruik. Een transactie boven een aangewezen bedrag kan echter een beheerd apparaat vereisen. Ontwikkelaars kunnen IT-beheerders in staat stellen stapsgewijs beleid voor voorwaardelijke toegang toe te wijzen aan verschillende gebieden van een toepassing door de verificatiecontext voor voorwaardelijke toegang te implementeren. De ontwikkelaarshandleiding voor verificatiecontext voor voorwaardelijke toegang is een goede referentie voor deze functies.

Standaard geeft Microsoft Entra ID toegangstokens op die geldig zijn voor een ingestelde tijd. Toepassingen mogen nooit de lengte van hun levenscyclus veronderstellen. Ze moeten de expires_in parameter gebruiken die Microsoft Entra ID teruggeeft met het toegangstoken. MSAL verwerkt dit scenario automatisch. Gedurende de levensduur van het toegangstoken heeft de gebruiker toestemming om toegang te krijgen tot de resource onder de voorwaarden op het moment van autorisatie.

De vertraging tussen wanneer voorwaarden veranderen en wanneer het afdwingen van beleidswijziging plaatsvindt, kan betrekking hebben op beheerders en gebruikers. Wanneer een gebruiker bijvoorbeeld een apparaat verliest, kan de IT-beheerder de sessies van de gebruiker intrekken. Een app op het verloren apparaat kan echter toegang blijven krijgen tot Microsoft Graph voor de gebruiker totdat het token verloopt. Microsoft-evaluatie van continue toegang (CAE) kan toegang voorkomen nadat gebruikerssessies zijn ingetrokken voor toepassingen die CAE gebruiken. Als uw toepassing Microsoft Graph minstens één keer per uur aanroept, kunt u CAE gebruiken. Het gebruik van API's voor continue toegangsevaluatie in uw toepassingen biedt implementatiedetails.

Als u niet kunt bouwen op MSAL, moet uw app OAuth 2.0 gebruiken om toegangstokens van Microsoft Entra-id aan te vragen. Microsoft Identity Platform en OAuth 2.0-autorisatiecodestroom bieden implementatiedetails voor de stromen die door Microsoft Entra ID worden ondersteund.

Als u apps voor mobiele apparaten bouwt, bekijk dan het beleid voor ondersteuning van eenmalige aanmelding (SSO) en app-beveiligingsbeleid in uw mobiele apps. Meer informatie over het ondersteunen van tokenverwerving, Intune Mobile Application Management (MAM) en app-beveiligingsbeleid.

Autorisatie in resources (API's)

In de sectie Autorisatie in toepassingen zijn drie vereiste autorisaties geïntroduceerd wanneer toepassingen toegang nodig hebben tot resources voor een gebruiker, maar alleen de eerste twee. De gebruiker moet gemachtigd zijn om toegang te krijgen tot een resource, maar Microsoft Entra-id voert de uiteindelijke autorisatie niet uit. De resource (API) voert de autorisatie uit.

API's moeten twee autorisaties afdwingen bij het handelen voor een gebruiker:

  • API's moeten een app machtigen om de API aan te roepen. Controleer of de claim van het toegangstoken scp (bereik) het vereiste bereik bevat.
  • API's moeten de gebruiker machtigen om toegang te krijgen tot de specifieke resource. De oid claims (object-id) en sub (onderwerp) in het token vertegenwoordigen de gebruikersidentiteit.

We raden de oid en sub claims voor autorisatie aan.

Microsoft Entra ID implementeert een paargewijze sub claim, daarom is de sub claim een unieke gebruikers-id voor de aanvragende app. Dezelfde gebruiker die een andere app gebruikt, heeft een andere sub claim. De oid claim is voor alle apps constant voor de gebruiker.

Toepassingen verstrekken het vereiste toegangstoken in de aanvraagautorisatieheader als een bearer-token voor API's die door Microsoft Entra ID worden beveiligd. API's moeten het ontvangen token volledig valideren omdat het token niet rechtstreeks afkomstig is van Microsoft Entra-id. Houd rekening met de aanroepende app als onbetrouwbaar totdat tokenvalidatie is uitgevoerd. De artikelen over naslaginformatie over toegangstokens en claimsvalidatiereferentie bieden informatie over het valideren van Microsoft Entra ID-toegangstokens.

Microsoft Entra ID publiceert de openbare sleutels die API's gebruiken om de handtekening van het token te valideren. Deze sleutels worden periodiek vernieuwd en wanneer de situatie om vernieuwing van de openbare sleutel vraagt. Uw toepassing mag nooit uitgaan van een vaste planning voor rollover van openbare sleutels. Rollover van ondertekeningssleutels in het Microsoft Identity Platform legt uit hoe u de rollover van openbare sleutels goed kunt afhandelen.

U wordt aangeraden een goed onderhouden bibliotheek te gebruiken om tokenvalidatie uit te voeren. Als u een web-app of API bouwt op ASP.NET of ASP.NET Core, gebruikt Microsoft.Identity.Web u dit om tokenvalidatie af te handelen. In het artikel over de instructies voor de beveiligde web-API wordt uitgelegd hoe u een API kunt beveiligen Microsoft.Identity.Web .

API's moeten soms andere API's aanroepen. Wanneer een app voor de gebruiker werkt, ontvangt de API een gedelegeerd toegangstoken dat de identiteit van de huidige gebruiker bevat. Het is belangrijk dat de API alleen een gevalideerd token van Microsoft Entra ID vertrouwt om de identiteit van de huidige gebruiker te bepalen. Met deze aanpak voorkomt u inbreuk op toepassingen, zodat gebruikers andere gebruikers imiteren en toegang krijgen tot resources voor een andere gebruiker. Voor dezelfde beveiliging wanneer een API een andere API aanroept, gebruikt u de OAuth-procedure Namens om een toegangstoken te verkrijgen waarmee u een API kunt aanroepen voor de gebruiker waarvoor de API is aangeroepen. Bouw een web-API die web-API's aanroept, biedt stappen voor een API om andere API's aan te roepen voor de huidige app-gebruiker.

Naast gedelegeerde toegang moeten API's mogelijk toepassingen ondersteunen en onafhankelijk werken zonder huidige gebruikers. Microsoft Entra-id verwijst naar deze toepassingen als workloads. Om workloadautorisatie af te dwingen, gebruiken API's de scp claim (scope) niet. In plaats daarvan gebruiken API's de roles claim om te controleren of de werkbelasting over de vereiste toestemming beschikt. API's zijn verantwoordelijk voor het afdwingen dat de workload autorisatie heeft voor toegang tot de resource.

Autorisatie in workloads

Workloads zijn toepassingen die onafhankelijk werken en geen huidige gebruiker hebben. Net als gedelegeerde toegang die wordt besproken in de sectie Autorisatie in toepassingen , zijn voor app-toegang verschillende autorisaties vereist:

  • De toepassing moet zijn gemachtigd om toegang te krijgen tot specifieke bewerkingen binnen specifieke resources.
  • De toepassing moet gemachtigd zijn om toegang te krijgen tot de resource onder de huidige voorwaarden.
  • De toepassing moet gemachtigd zijn om toegang te krijgen tot de resource.

Het proces begint met een workload die een toegangstoken aanvraagt met het .default bereik (zoals https://graph.microsoft.com/.default). In tegenstelling tot gedelegeerde toegang (toepassingen kunnen dynamisch en incrementeel aanvraagbereiken aanvragen), moeten workloads altijd statische toestemming en het .default bereik gebruiken.

API-ontwerpers maken app-machtigingen voor hun API door rollen toe te voegen aan de app-registratie van de API. Deze rollen hebben een toegestaan lidtype van toepassingen, waarmee roltoewijzing aan workloads mogelijk is. Wijs rollen toe aan workloads in het Microsoft Entra-beheercentrum of met Microsoft Graph. In het Microsoft Entra-beheercentrum is beheerderstoestemming nodig voor de toegewezen rollen voordat de workload kan worden uitgevoerd.

Standaard autoriseert een app-machtiging de workloads voor toegang tot alle exemplaren van een resource. Autoriseert bijvoorbeeldhttps://graph.microsoft.com/user.read.all een workload voor toegang tot het volledige gebruikersprofiel van elke gebruiker in de tenant. IT-beheerders zijn vaak niet bereid om deze brede machtigingen te verlenen.

Voor workloads die toegang hebben tot Microsoft Graph, gebruikt u deze methoden om de toepassingsmachtiging te beperken:

In tegenstelling tot toepassingen met gebruikers worden workloads geverifieerd bij Microsoft Entra ID.

Voor workloads die worden uitgevoerd in Microsoft Azure, is de beste methode voor een workload om zichzelf te verifiëren beheerde identiteiten voor Azure-resources. De functie beheerde identiteiten verwijdert de noodzaak om referenties voor de workload te beheren. Er zijn geen toegankelijke referenties. Microsoft Entra ID beheert referenties volledig. Zonder aanmeldgegevens die moeten worden beheerd, zijn er geen aanmeldgegevens die risico lopen gecompromitteerd te worden.

Met verbeterde beveiliging vergroten beheerde identiteiten ook de tolerantie. Beheerde identiteiten maken gebruik van langlevende toegangstokens en informatie van Microsoft Entra ID om nieuwe tokens op te halen voordat tokens verlopen. Beheerde identiteiten maken gebruik van regionale eindpunten die helpen bij het voorkomen van storingen buiten de regio door serviceafhankelijkheden te consolideren. Regionale eindpunten helpen verkeer in een geografisch gebied te behouden. Als uw Azure-resource zich bijvoorbeeld in WestUS2 bevindt, blijft al het verkeer in WestUS2.

Als de workload niet wordt uitgevoerd in Microsoft Azure, moet de workload zichzelf verifiëren met de OAuth 2.0-clientreferentiestroom.

Microsoft Entra ID ondersteunt deze clientreferentietypen:

  • Certificaat. Workloads bewijzen dat ze een persoonlijke sleutel hebben door een verklaring met de persoonlijke sleutel te ondertekenen. De persoonlijke sleutel wordt niet verzonden naar Microsoft Entra-id. Alleen de verklaring wordt verzonden. We raden certificaten aan in plaats van clientgeheimen omdat ze veiliger en vaak beter worden beheerd.
  • Federatieve referentie. Workload Identity Federation stelt workloads die niet op Microsoft Azure draaien in staat een identiteit van een andere identiteitsprovider, GitHub Actions of een Kubernetes-cluster te gebruiken. Workloads vragen tokens op dezelfde manier aan voor federatieve referenties als voor certificaatreferenties. Het verschil is dat de assertie, een ondertekend JSON-webtoken, afkomstig is van de federatie-id-provider.
  • Clientgeheim. Een clientgeheim, ook wel een toepassingswachtwoord genoemd, is een tekenreekswaarde die de workload kan gebruiken om zichzelf te identificeren. De tekstwaarde van het geheim wordt van de werkbelasting naar Microsoft Entra-id verzonden in een POST-aanvraag voor een token. Clientgeheimen zijn minder veilig dan certificaten of workload-identiteitsfederatie. Als uw workload geheimen gebruikt, volgt u deze aanbevolen procedures voor het beheren van geheimen.

Naast Microsoft Entra ID bevat de Microsoft Entra-productfamilie Microsoft Entra Workload-ID. Microsoft Entra Workload-ID beschikt over de volgende Premium-functies om de workloadbeveiliging te verbeteren.

  • Voorwaardelijke toegang ondersteunt locatie- of risicogebaseerde beleidsregels voor workloadidentiteiten.
  • Microsoft Entra ID Protection biedt rapporten over verdachte referenties, afwijkende aanmeldingen en verdachte wijzigingen in accounts.
  • Met toegangsbeoordelingen kunt u delegering van controle naar de juiste personen inschakelen, gericht op de belangrijkste bevoorrechte rollen.
  • Aanbevelingen voor app-gezondheid stellen manieren voor om hiaten in identiteitsbeheer in uw toepassingsportfolio aan te pakken en de tenantbeveiliging en de veerkrachtpositie te verbeteren.

Workloads kunnen ondersteuning bieden voor continue toegangsevaluatie (CAE) als ze Microsoft Graph ten minste één keer per uur aanroepen. Ter ondersteuning van CAE moet de workload een single-tenanttoepassing zijn en moet de app geregistreerd zijn in de tenant waar het toegang heeft tot Microsoft Graph. Als uw workload aan deze vereisten voldoet, raadpleegt u dit voorbeeld voor implementatiestappen.

Volgende stappen

  • Last updated on