Informatie over gedelegeerde toegang
Wanneer een gebruiker zich aanmeldt bij een app en deze gebruikt voor toegang tot een andere resource, zoals Microsoft Graph, moet de app eerst toestemming vragen om toegang te krijgen tot deze resource namens de gebruiker. Dit algemene scenario wordt gedelegeerde toegang genoemd.
Waarom moet ik gedelegeerde toegang gebruiken?
Mensen gebruiken vaak verschillende toepassingen om toegang te krijgen tot hun gegevens vanuit cloudservices. Iemand wil bijvoorbeeld een favoriete PDF-lezertoepassing gebruiken om bestanden weer te geven die zijn opgeslagen in hun OneDrive. Een ander voorbeeld kan de Line-Of-Business-toepassing van een bedrijf zijn die gedeelde informatie over hun collega's kan ophalen, zodat ze eenvoudig revisoren voor een aanvraag kunnen kiezen. In dergelijke gevallen moeten de clienttoepassing, de PDF-lezer of het goedkeuringsprogramma van het bedrijf worden geautoriseerd om toegang te krijgen tot deze gegevens namens de gebruiker die zich heeft aangemeld bij de toepassing.
Gebruik gedelegeerde toegang wanneer u een aangemelde gebruiker toegang wilt geven met hun eigen resources of resources die ze kunnen openen. Of het nu een beheerder is die beleidsregels instelt voor de hele organisatie of een gebruiker die een e-mailbericht verwijdert in zijn Postvak IN, alle scenario's met betrekking tot gebruikersacties moeten gedelegeerde toegang gebruiken.
Gedelegeerde toegang is daarentegen meestal een slechte keuze voor scenario's die moeten worden uitgevoerd zonder een aangemelde gebruiker, zoals automatisering. Het kan ook een slechte keuze zijn voor scenario's die betrekking hebben op toegang tot de resources van veel gebruikers, zoals preventie van gegevensverlies of back-ups. Overweeg om alleen toegang tot toepassingen te gebruiken voor deze typen bewerkingen.
Bereiken aanvragen als client-app
Uw app moet de gebruiker vragen om een specifiek bereik of een set bereiken te verlenen voor de resource-app die u wilt openen. Bereiken kunnen ook wel gedelegeerde machtigingen worden genoemd. Deze bereiken beschrijven welke resources en bewerkingen uw app namens de gebruiker wil uitvoeren. Als u bijvoorbeeld wilt dat uw app de gebruiker een lijst met onlangs ontvangen e-mailberichten en chatberichten weergeeft, kunt u de gebruiker vragen toestemming te geven voor Microsoft Graph Mail.Read en Chat.Read bereiken.
Zodra uw app een bereik heeft aangevraagd, moet een gebruiker of beheerder de aangevraagde toegang verlenen. Consumentengebruikers met Microsoft-accounts, zoals Outlook.com of Xbox Live-accounts, kunnen altijd bereiken voor zichzelf verlenen. Organisatiegebruikers met Microsoft Entra-accounts kunnen al dan niet bereiken verlenen, afhankelijk van de instellingen van hun organisatie. Als een organisatiegebruiker niet rechtstreeks toestemming kan geven voor bereiken, moet hij of zij de beheerder van de organisatie vragen om toestemming te geven.
Volg altijd het principe van minimale bevoegdheden: u moet nooit bereiken aanvragen die uw app niet nodig heeft. Dit principe helpt het beveiligingsrisico te beperken als uw app is gecompromitteerd en maakt het beheerders gemakkelijker om uw app toegang te verlenen. Als uw app bijvoorbeeld alleen de chats moet vermelden waartoe een gebruiker behoort, maar de chatberichten niet zelf hoeft weer te geven, moet u het beperktere Microsoft Graph-bereik Chat.ReadBasic aanvragen in plaats van Chat.Read. Zie OpenID-bereiken voor meer informatie over openID-bereiken.
Bereiken voor een resourceservice ontwerpen en publiceren
Als u een API bouwt en gedelegeerde toegang wilt toestaan namens gebruikers, moet u bereiken maken die andere apps kunnen aanvragen. Deze bereiken moeten de acties of resources beschrijven die beschikbaar zijn voor de client. Houd rekening met scenario's voor ontwikkelaars bij het ontwerpen van uw bereiken.
Token naar zichzelf
In het scenario waarin:
- De resourcetoepassing en clienttoepassing zijn hetzelfde.
- De toepassing heeft geen geregistreerde web-API.
- De toepassing vraagt een token aan voor een gedelegeerde machtiging die zichzelf beschikbaar maakt
Er is geen toestemming nodig of weergegeven voor deze tokenaanvraag. Bovendien kunnen apps die in een tenant worden gemaakt en een token aan zichzelf aanvragen, worden afgeleid om al toegang te hebben tot profielgegevens en worden automatisch profieltoegang verleend.
Hoe werkt gedelegeerde toegang?
Het belangrijkste om te onthouden over gedelegeerde toegang is dat zowel uw client-app als de aangemelde gebruiker correct moeten worden geautoriseerd. Het verlenen van een bereik is niet voldoende. Als de client-app niet het juiste bereik heeft of als de gebruiker niet over voldoende rechten beschikt om de resource te lezen of te wijzigen, mislukt de aanroep.
- Autorisatie van client-apps: client-apps worden geautoriseerd door bereiken te verlenen. Wanneer aan een client-app een bereik wordt verleend door een gebruiker of beheerder voor toegang tot een bepaalde resource, wordt die toekenning vastgelegd in Microsoft Entra-id. Alle gedelegeerde toegangstokens die door de client worden aangevraagd voor toegang tot de resource namens de relevante gebruiker, bevatten vervolgens de claimwaarden van deze bereiken in de
scpclaim. De resource-app controleert deze claim om te bepalen of de client-app het juiste bereik voor de aanroep heeft gekregen. - Gebruikersautorisatie : gebruikers worden geautoriseerd door de resource die u aanroept. Resource-apps kunnen een of meer systemen gebruiken voor gebruikersautorisatie, zoals op rollen gebaseerd toegangsbeheer, eigendoms-/lidmaatschapsrelaties, toegangsbeheerlijsten of andere controles. Microsoft Entra ID controleert bijvoorbeeld of een gebruiker is toegewezen aan een rol van app-beheer of algemene beheerder voordat ze de toepassingen van een organisatie mogen verwijderen, maar ook alle gebruikers toestaan toepassingen te verwijderen waarvan ze eigenaar zijn. Op dezelfde manier controleert de SharePoint Online-service of een gebruiker over de juiste eigenaars- of lezerrechten voor een bestand voordat deze gebruiker het kan openen.
Voorbeeld van gedelegeerde toegang - OneDrive via Microsoft Graph
Kijk een naar het volgende voorbeeld:
Alice wil een client-app gebruiken om een bestand te openen dat wordt beveiligd door een resource-API, Microsoft Graph. Voor gebruikersautorisatie controleert de OneDrive-service of het bestand is opgeslagen op het station van Alice. Als het is opgeslagen op het station van een andere gebruiker, weigert OneDrive het verzoek van Alice als onbevoegd, omdat Alice niet het recht heeft om stations van andere gebruikers te lezen.
Voor autorisatie van client-apps controleert OneDrive of de client die de aanroep doet, het Files.Read bereik heeft gekregen namens de aangemelde gebruiker. In dit geval is de aangemelde gebruiker Alice. Als Files.Read niet is verleend aan de app voor Alice, mislukt oneDrive ook de aanvraag.
| GET /drives/{id}/files/{id} | Client-app verleend Files.Read bereik voor Alice |
Client-app heeft geen bereik verleend Files.Read voor Alice |
|---|---|---|
| Het document bevindt zich in De OneDrive van Alice. | 200 – Toegang verleend. | 403 - Niet geautoriseerd. Alice (of haar beheerder) heeft deze client niet toegestaan om haar bestanden te lezen. |
| Het document bevindt zich in oneDrive van een andere gebruiker*. | 403 - Niet geautoriseerd. Alice heeft geen rechten om dit bestand te lezen. Hoewel de klant is verleend Files.Read , moet deze worden geweigerd bij het handelen namens Alice. |
403 – Niet geautoriseerd. Alice heeft geen rechten om dit bestand te lezen en de client mag ook geen bestanden lezen waar ze toegang toe heeft. |
Het gegeven voorbeeld is vereenvoudigd om gedelegeerde autorisatie te illustreren. De OneDrive-productieservice ondersteunt veel andere toegangsscenario's, zoals gedeelde bestanden.