Identifiera behörigheter och medgivande

  • 3 minuter

Program som integreras med Microsofts identitetsplattform följa en auktoriseringsmodell som ger användare och administratörer kontroll över hur data kan nås.

Microsofts identitetsplattform implementerar OAuth 2.0-auktoriseringsprotokollet. OAuth 2.0 är en metod genom vilken en app från tredje part kan komma åt webbaserade resurser för en användares räkning. Alla webbaserade resurser som integreras med Microsofts identitetsplattform har en resursidentifierare eller program-ID-URI.

Här är några exempel på Microsofts webbaserade resurser:

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

Detsamma gäller för alla resurser från tredje part som är integrerade med Microsofts identitetsplattform. Alla dessa resurser kan också definiera en uppsättning behörigheter som kan användas för att dela upp funktionen för resursen i mindre segment. När en resurss funktioner delas in i små behörighetsuppsättningar kan appar från tredje part skapas för att endast begära de behörigheter som de behöver för att utföra sin funktion. Användare och administratörer kan veta vilka data som appen kan komma åt.

I OAuth 2.0 kallas dessa typer av behörighetsuppsättningar för omfång. De kallas också ofta för behörigheter. I Microsofts identitetsplattform representeras en behörighet som ett strängvärde. En app begär de behörigheter den behöver genom att ange behörigheten i frågeparametern scope . Identitetsplattformen stöder flera väldefinierade OpenID Connect-omfång och resursbaserade behörigheter (varje behörighet anges genom att behörighetsvärdet läggs till i resursens identifierare eller program-ID URI). Till exempel används behörighetssträngen https://graph.microsoft.com/Calendars.Read för att begära behörighet att läsa användarnas kalendrar i Microsoft Graph.

En app begär vanligtvis dessa behörigheter genom att ange omfången i begäranden till Microsofts identitetsplattform auktorisera slutpunkten. Vissa behörigheter med hög behörighet kan dock endast beviljas genom administratörsmedgivande. De kan begäras eller beviljas med hjälp av slutpunkten för administratörsmedgivande.

Kommentar

I begäranden om auktorisering, token eller medgivandeslutpunkter för Microsoft Identity Platform antas resursen vara Microsoft Graph om resursidentifieraren utelämnas i omfångsparametern. scope=User.Read motsvarar till exempel https://graph.microsoft.com/User.Read.

Behörighetstyper

Microsofts identitetsplattform stöder två typer av behörigheter: delegerad åtkomst och åtkomst endast för appar.

  • Delegerad åtkomst används av appar som har en inloggad användare närvarande. För dessa appar godkänner antingen användaren eller en administratör de behörigheter som appen begär. Appen delegeras med behörighet att agera som en inloggad användare vid anrop till målresursen.

  • Åtkomstbehörigheter endast för appar används av appar som körs utan en inloggad användare, till exempel appar som körs som bakgrundstjänster eller daemoner. Endast en administratör kan godkänna åtkomstbehörigheter endast för appar.

Program i Microsofts identitetsplattform förlitar sig på medgivande för att få åtkomst till nödvändiga resurser eller API:er. Det finns många typer av medgivande som din app kan behöva känna till för att lyckas. Om du definierar behörigheter måste du också förstå hur användarna får åtkomst till din app eller ditt API.

Det finns tre medgivandetyper: statiskt användarmedgivande, inkrementellt och dynamiskt användarmedgivande och administratörsmedgivande.

I scenariot med statiskt användarmedgivande måste du ange alla behörigheter som krävs i appens konfiguration i Azure Portal. Om användaren (eller administratören efter behov) inte har beviljat medgivande för den här appen uppmanar Microsofts identitetsplattform användaren att ge sitt medgivande just nu. Statiska behörigheter gör det också möjligt för administratörer att samtycka åt alla användare i organisationen.

Även om statiska behörigheter för appen som definierats i Azure Portal hålla koden fin och enkel, ger den några möjliga problem för utvecklare:

  • Appen måste begära alla behörigheter som den skulle behöva vid användarens första inloggning. Detta kan leda till en lång lista med behörigheter som avråder slutanvändarna från att godkänna appens åtkomst vid den första inloggningen.

  • Appen måste känna till alla resurser som den någonsin skulle komma åt i förväg. Det är svårt att skapa appar som kan komma åt ett godtyckligt antal resurser.

Med Microsofts identitetsplattform slutpunkten kan du ignorera de statiska behörigheter som definierats i appregistreringsinformationen i Azure Portal och begära behörigheter stegvis i stället. Du kan be om en minsta uppsättning behörigheter i förväg och begära mer över tid eftersom kunden använder fler appfunktioner.

För att göra det kan du ange de omfång som din app behöver när som helst genom att inkludera de nya omfången i parametern scope när du begär en åtkomsttoken – utan att behöva fördefiniera dem i programregistreringsinformationen. Om användaren ännu inte har samtyckt till nya omfång som lagts till i begäran uppmanas de endast att godkänna de nya behörigheterna. Inkrementellt eller dynamiskt medgivande gäller endast för delegerade behörigheter och inte för åtkomstbehörigheter endast för appar.

Viktigt!

Ett dynamiskt godkännande kan vara praktiskt, men det är en utmaning för behörigheter som kräver administratörsmedgivande eftersom man inte känner till dessa behörigheter vid godkännandet. Om du behöver administratörsbehörigheter eller om din app använder dynamiskt medgivande måste du registrera alla behörigheter i Azure Portal (inte bara den delmängd av behörigheter som kräver administratörsmedgivande). Detta gör det möjligt för klientadministratörer att godkänna för alla sina användares räkning.

Administratörsmedgivande krävs när din app behöver åtkomst till vissa behörigheter med hög behörighet. Administratörsmedgivande säkerställer att administratörer har vissa andra kontroller innan de ger appar eller användare åtkomst till mycket privilegierade data från organisationen.

Administratörsmedgivande som görs för en organisations räkning kräver fortfarande de statiska behörigheter som registrerats för appen. Ange dessa behörigheter för appar i appregistreringsportalen om du behöver en administratör för att ge medgivande åt hela organisationen. Detta minskar de cykler som krävs av organisationsadministratören för att konfigurera programmet.

I en OpenID Connect- eller OAuth 2.0-auktoriseringsbegäran kan en app begära de behörigheter den behöver med hjälp av frågeparametern omfång. När en användare till exempel loggar in på en app skickar appen en begäran som i följande exempel. Radbrytningar läggs till för läsbarhet.

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

Parametern scope är en blankstegsavgränsad lista över delegerade behörigheter som appen begär. Varje behörighet anges genom att behörighetsvärdet läggs till i resursens identifierare (program-ID-URI). I begärandeexemplet behöver appen behörighet att läsa användarens kalender och skicka e-post som användare.

När användaren har angett sina autentiseringsuppgifter söker Microsofts identitetsplattform efter en matchande post med användarmedgivande. Om användaren inte har samtyckt till någon av de begärda behörigheterna tidigare, och om administratören inte har samtyckt till dessa behörigheter för hela organisationens räkning, ber Microsofts identitetsplattform användaren att bevilja de begärda behörigheterna.