Behörigheter och medgivande i Microsofts identitetsplattform

Program som integreras med Microsofts identitetsplattform följer en auktoriseringsmodell som ger användare och administratörer kontroll över hur data kan nås. Implementeringen av auktoriseringsmodellen har uppdaterats på Microsofts identitetsplattform. Den ändrar hur en app måste interagera med Microsofts identitetsplattform. Den här artikeln beskriver grundläggande begrepp för den här auktoriseringsmodellen, inklusive omfattningar, behörigheter och medgivande.

Omfång och behörigheter

Autentiseringsprotokollet Microsofts identitetsplattform OAuth 2.0-auktoriseringsprotokollet. OAuth 2.0 är en metod genom vilken en tredjepartsapp kan komma åt webbaserade resurser för en användares räkning. Alla webbaserade resurser som integreras med den här Microsofts identitetsplattform en resursidentifierare eller program-ID-URI.

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

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

Samma sak gäller för alla resurser från tredje part som har integrerats med Microsofts identitetsplattform. Alla dessa resurser kan också definiera en uppsättning behörigheter som kan användas för att dela upp funktionerna i resursen i mindre segment. Till exempel har Microsoft Graph definierat behörigheter för att utföra följande uppgifter, bland annat:

• Läsa en användares kalender
• Skriva till en användares kalender
• Skicka e-post som en användare

På grund av dessa typer av behörighetsdefinitioner har resursen en finkornig kontroll över sina data och hur API-funktioner exponeras. En tredjepartsapp kan begära dessa behörigheter från användare och administratörer som måste godkänna begäran innan appen kan komma åt data eller agera för en användares räkning.

När en resurs funktioner är indelade i små behörighetsuppsättningar, kan appar från tredje part byggas 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. Och de kan vara säkrare på att appen inte beter sig med skadlig avsikt. Utvecklare bör alltid följa principen om minsta behörighet och endast be om de behörigheter som de behöver för att programmen ska fungera.

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 som behövs genom att ange behörigheten i scope frågeparametern. Identitetsplattformen har stöd för flera väldefinierade OpenID Anslut-omfång samt resursbaserade behörigheter (varje behörighet anges genom att behörighetsvärdet till resursens identifierare eller program-ID-URI har angetts). Till exempel används https://graph.microsoft.com/Calendars.Read behörighetssträngen för att begära behörighet att läsa användarnas kalendrar i Microsoft Graph.

En app begär oftast 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. Läs vidare om du vill veta mer.

I begäranden till auktoriserings-, token- eller medgivandeslutpunkter för Microsoft Identity-plattformen 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

Den Microsofts identitetsplattform två typer av behörigheter: delegerade behörigheter och programbehörigheter.

• Delegerade behörigheter används av appar som har en inloggad användare. För dessa appar samtycker antingen användaren eller en administratör till de behörigheter som appen begär. Appen delegeras med behörighet att fungera som en inloggad användare när den gör anrop till målresursen.

  Vissa delegerade behörigheter kan godkännas av icke-administratörer. Men vissa högbehörigheter kräver administratörsmedgivande. Information om vilka administratörsroller som kan godkänna delegerade behörigheter finns i Behörigheter för administratörsroll i Azure Active Directory (Azure AD).

• Programbehörigheter används av appar som körs utan en inloggad användare, till exempel appar som körs som bakgrundstjänster eller daemon. Endast en administratör kan samtycka till programbehörigheter.

Gällande behörigheter är de behörigheter som din app har när den gör begäranden till målresursen. Det är viktigt att förstå skillnaden mellan de delegerade behörigheterna och programbehörigheterna som din app beviljas och de gällande behörigheter som appen beviljas när den gör anrop till målresursen.

• För delegerade behörigheter är de gällande behörigheterna för din app den minst privilegierade skärningspunkten för de delegerade behörigheter som appen har beviljats (genom medgivande) och behörigheterna för den inloggade användaren. Din app kan aldrig ha fler behörigheter än den inloggade användaren.

  Inom organisationer kan den inloggade användarens behörigheter fastställas av en princip eller genom medlemskap i en eller flera administratörsroller. Information om vilka administratörsroller som kan godkänna delegerade behörigheter finns i Behörigheter för administratörsroll i Azure AD.

  Anta till exempel att din app har beviljats behörigheten User.ReadWrite.All delegerad. Den här behörigheten ger i princip din app behörighet att läsa och uppdatera profilen för alla användare i en organisation. Om den inloggade användaren är en global administratör kan din app uppdatera profilen för alla användare i organisationen. Men om den inloggade användaren inte har någon administratörsroll kan din app bara uppdatera profilen för den inloggade användaren. Den kan inte uppdatera profiler för andra användare i organisationen eftersom den användare som den har behörighet att agera för inte har dessa behörigheter.

• För programbehörigheter är de gällande behörigheterna för din app den fullständiga behörighetsnivå som behörigheten ger. Till exempel kan en app som har behörigheten User.ReadWrite.All uppdatera profilen för varje användare i organisationen.

OpenID Anslut omfång

Implementeringen Microsofts identitetsplattform OpenID Anslut har några väldefinierade omfång som också finns på Microsoft Graph: openid , , och email profile offline_access . address phone OpenID-Anslut-omfång stöds inte.

Om du begär OpenID Anslut omfång och en token får du en token för att anropa UserInfo-slutpunkten.

Openid

Om en app loggar in med hjälp av OpenID Anslutmåste den begära openid omfånget. openidOmfånget visas på sidan för medgivande till arbetskonto som behörigheten Logga in. På sidan för Microsoft-konto personliga behörigheter visas den som Visa din profil och ansluta till appar och tjänster med din Microsoft-konto behörighet.

Med den här behörigheten kan en app ta emot en unik identifierare för användaren i form av sub anspråket. Behörigheten ger även appen åtkomst till userInfo-slutpunkten. openidOmfånget kan användas vid Microsofts identitetsplattform för att hämta ID-token. Appen kan använda dessa token för autentisering.

e-post

emailOmfånget kan användas med openid omfånget och andra omfång. Det ger appen åtkomst till användarens primära e-postadress i form av email anspråket.

Anspråket ingår endast i en token om en e-postadress är associerad med användarkontot, vilket email inte alltid är fallet. Om appen använder omfånget måste appen kunna hantera email ett fall där det inte finns några anspråk i email token.

profil

profileOmfånget kan användas med openid omfånget och andra omfång. Det ger appen åtkomst till en stor mängd information om användaren. Den information som den kan komma åt omfattar, men är inte begränsad till, användarens förnamn, efternamn, användarnamn och objekt-ID.

En fullständig lista över anspråk profile som är tillgängliga i id_tokens parametern för en specifik användare finns i id_tokens referensen.

offline_access

offline_access Omfånget ger din app åtkomst till resurser för användarens räkning under en längre tid. På sidan för medgivande visas det här omfånget som Den behåller åtkomsten till data som du har gett åtkomst till behörighet.

När en användare godkänner offline_access omfånget kan appen ta emot uppdateringstoken från Microsofts identitetsplattform tokenslutpunkt. Uppdateringstoken är långlivade. Din app kan hämta nya åtkomsttoken när äldre upphör att gälla.

På Microsofts identitetsplattform (begäranden som görs till v2.0-slutpunkten) måste din app uttryckligen begära offline_access omfånget för att ta emot uppdateringstoken. Så när du löser in en auktoriseringskod i OAuth 2.0-auktoriseringskodflödetfår du bara en åtkomsttoken från /token slutpunkten.

Åtkomsttoken är giltig under en kort tid. Den upphör vanligtvis att gälla om en timme. Då måste appen omdirigera användaren tillbaka till slutpunkten för att /authorize få en ny auktoriseringskod. Beroende på typen av app kan användaren under omdirigeringen behöva ange sina autentiseringsuppgifter igen eller godkänna behörigheterna igen.

Mer information om hur du hämtar och använder uppdateringstoken finns i Microsofts identitetsplattform protokollreferens .

Medgivandetyper

Program i Microsofts identitetsplattform förlitar sig på medgivande för att få åtkomst till nödvändiga resurser eller API:er. Det finns ett antal typer av godkännanden som din app kan behöva ha för att fungera. Om du definierar behörigheter behöver du också känna till hur användarna får tillgång till din app eller API.

Statiskt användarmedgivande

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 gett sitt medgivande för den här appen Microsofts identitetsplattform användaren att ge sitt medgivande just nu.

Statiska behörigheter gör det också möjligt för administratörer att godkänna för alla användare i organisationen.

Statiska behörigheter för appen som definierats i Azure Portal hålla koden snygg och enkel, men det medför några möjliga problem för utvecklare:

• Appen måste begära alla behörigheter som behövs vid användarens första inloggning. Detta kan leda till en lång lista över behörigheter som avråder slutanvändare 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 ha åtkomst till i förväg. Det är svårt att skapa appar som kan komma åt ett godtyckligt antal resurser.

Inkrementellt och dynamiskt användarmedgivande

Med Microsofts identitetsplattform slutpunkten kan du ignorera de statiska behörigheter som definierats i appregistreringsinformationen i Azure Portal och begära behörigheter inkrementellt i stället. Du kan be om en minimal uppsättning behörigheter direkt och begära mer över tid eftersom kunden använder ytterligare appfunktioner. För att göra det kan du när som helst ange de omfång som din app behöver genom att inkludera de nya omfången i parametern när du begär en åtkomsttoken – utan att behöva definiera dem i scope programregistreringsinformationen. Om användaren ännu inte har samtyckt till nya omfång som lagts till i begäran uppmanas de att endast godkänna de nya behörigheterna. Inkrementellt eller dynamiskt medgivande gäller endast delegerade behörigheter och inte programbehörigheter.

Genom att tillåta en app att begära behörigheter dynamiskt via scope parametern får utvecklare fullständig kontroll över användarens upplevelse. Du kan också läsa in din medgivandeupplevelse och be om alla behörigheter i en inledande auktoriseringsbegäran. Om din app kräver ett stort antal behörigheter kan du samla in dessa behörigheter från användaren inkrementellt när de försöker använda vissa funktioner i appen över tid.

Administratörsmedgivande

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 ytterligare kontroller innan de godkänner appar, eller att användare får åtkomst till högprivilegierade 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 organisationens administratör för att konfigurera programmet.

Begära enskilt användarmedgivande

I en OpenID Anslut- eller OAuth 2.0-auktoriseringsbegäran kan en app begära de behörigheter som behövs med hjälp av scope frågeparametern. När en användare till exempel loggar in på en app skickar appen en begäran som i följande exempel. (Radbrytningar har lagts till för att göra dem mer läsbarhet.)

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&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 lägga till behörighetsvärdet till resursens identifierare (program-ID-URI). I exemplet med begäran behöver appen behörighet att läsa användarens kalender och skicka e-post som användaren.

När användaren anger sina autentiseringsuppgifter söker Microsofts identitetsplattform efter en matchande post med användarens medgivande. 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.

Just nu inkluderas behörigheten ("Upprätthålla åtkomst till data som du har gett åtkomst till") och ("Logga in och läsa din profil") automatiskt i det första medgivandet till offline_access user.read ett program. Dessa behörigheter krävs vanligtvis för att appen ska fungera korrekt. Behörigheten offline_access ger appen åtkomst till uppdateringstoken som är viktiga för interna appar och webbappar. Behörigheten user.read ger åtkomst till sub anspråket. Det gör att klienten eller appen kan identifiera användaren över tid och få åtkomst till enkel användarinformation.

När användaren godkänner behörighetsbegäran registreras medgivande. Användaren behöver inte ge sitt medgivande igen när de senare loggar in i programmet.

Begära medgivande för en hel klientorganisation

När en organisation köper en licens eller prenumeration för ett program vill organisationen ofta proaktivt konfigurera programmet för användning av alla medlemmar i organisationen. Som en del av den här processen kan en administratör bevilja medgivande för programmet att agera för en användares räkning i klientorganisationen. Om administratören ger medgivande för hela klientorganisationen ser inte organisationens användare någon medgivandesida för programmet.

Administratörsmedgivande som görs för en organisations räkning kräver 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.

Appen kan använda slutpunkten för administratörsmedgivande för att begära medgivande för delegerade behörigheter för alla användare i en klientorganisation.

Dessutom måste program använda slutpunkten för administratörsmedgivande för att begära programbehörigheter.

Administratörsbegränsade behörigheter

Vissa behörigheter med hög behörighet i Microsoft-resurser kan anges till administratörsbegränsade. Här följer några exempel på dessa typer av behörigheter:

• Läsa alla användares fullständiga profiler med hjälp av User.Read.All
• Skriva data till en organisations katalog med hjälp av Directory.ReadWrite.All
• Läsa alla grupper i en organisations katalog med hjälp av Groups.Read.All

Även om en konsumentanvändare kan ge ett program åtkomst till den här typen av data kan organisationsanvändare inte bevilja åtkomst till samma uppsättning känsliga företagsdata. Om ditt program begär åtkomst till någon av dessa behörigheter från en organisationsanvändare får användaren ett felmeddelande om att de inte har behörighet att godkänna appens behörigheter.

Om din app kräver omfång för administratörsbegränsade behörigheter måste en organisations administratör godkänna dessa omfång för organisationens användares räkning. För att undvika att visa frågor för användare som begär medgivande för behörigheter som de inte kan bevilja kan din app använda slutpunkten för administratörsmedgivande. Slutpunkten för administratörsmedgivande tas upp i nästa avsnitt.

Om programmet begär delegerade behörigheter med hög behörighet och en administratör beviljar dessa behörigheter via slutpunkten för administratörsmedgivande, beviljas medgivande för alla användare i klientorganisationen.

Om programmet begär programbehörigheter och en administratör beviljar dessa behörigheter via slutpunkten för administratörsmedgivande görs detta beviljande inte för någon specifik användares räkning. I stället beviljas klientprogrammet behörigheter direkt. Dessa typer av behörigheter används endast av daemontjänster och andra icke-interaktiva program som körs i bakgrunden.

Använda slutpunkten för administratörsmedgivande

När du har använd slutpunkten för administratörsmedgivande för att bevilja administratörsmedgivande är du klar. Användarna behöver inte vidta några ytterligare åtgärder. När administratörsmedgivande har beviljats kan användarna få en åtkomsttoken via ett typiskt auth-flöde. Den resulterande åtkomsttoken har de behörigheter som krävs.

När en global administratör använder ditt program och dirigeras till auktorisera slutpunkten Microsofts identitetsplattform identifierar användarens roll. Den frågar om den globala administratören vill godkänna för hela klientorganisationens räkning för de behörigheter som du har begärt. Du kan i stället använda en dedikerad slutpunkt för administratörsmedgivande för att proaktivt begära att en administratör beviljar behörighet åt hela klientorganisationen. Den här slutpunkten är också nödvändig för att begära programbehörigheter. Programbehörigheter kan inte begäras med hjälp av auktorisera slutpunkten.

Om du följer de här stegen kan din app begära behörigheter för alla användare i en klientorganisation, inklusive administratörsbegränsade omfång. Den här åtgärden har hög behörighet. Använd endast åtgärden om det behövs för ditt scenario.

Ett kodexempel som implementerar stegen finns i exemplet med administratörsbegränsade omfång i GitHub.

Begära behörigheterna i appregistreringsportalen

I appregistreringsportalen kan program lista de behörigheter som krävs, inklusive både delegerade behörigheter och programbehörigheter. Den här konfigurationen tillåter användning av /.default omfånget och Azure Portal alternativet Bevilja administratörsmedgivande.

I allmänhet ska behörigheterna statiskt definieras för ett visst program. De bör vara en supermängd av de behörigheter som appen begär dynamiskt eller inkrementellt.

Så här konfigurerar du listan över statiskt begärda behörigheter för ett program:

1. Gå till ditt program i Azure Portal – Appregistreringar snabbstart.
2. Välj ett program eller skapa en app om du inte redan har gjort det.
3. På programmets översiktssida går du till Hantera och väljer API-behörigheter Lägg till en > behörighet.
4. Välj Microsoft Graph listan över tillgängliga API:er. Lägg sedan till de behörigheter som din app kräver.
5. Välj Lägg till behörigheter.

Rekommenderat: Logga in användaren i din app

När du skapar ett program som använder slutpunkten för administratörsmedgivande behöver appen normalt en sida eller vy där administratören kan godkänna appens behörigheter. Den här sidan kan vara:

• En del av appens inloggningsflöde.
• En del av appens inställningar.
• Ett dedikerat "anslut"-flöde.

I många fall är det klokt att appen bara visar den här anslutningsvyn när en användare har loggat in med en arbets- Microsoft-konto eller Microsoft-konto.

När du loggar in användaren i din app kan du identifiera organisationen som administratören tillhör innan du ber dem att godkänna de behörigheter som krävs. Även om det här steget inte är absolut nödvändigt kan det hjälpa dig att skapa en mer intuitiv upplevelse för organisationens användare.

Om du vill logga in användaren följer du Microsofts identitetsplattform självstudierna.

Begära behörigheter från en katalogadministratör

När du är redo att begära behörigheter från din organisations administratör kan du omdirigera användaren till slutpunkten för Microsofts identitetsplattform administratörsmedgivande.

// Line breaks are for legibility only.
GET https://login.microsoftonline.com/{tenant}/v2.0/adminconsent?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&state=12345
&redirect_uri=http://localhost/myapp/permissions
&scope=
https://graph.microsoft.com/calendars.read
https://graph.microsoft.com/mail.send

I det här läget kräver Azure AD att en innehavaradministratör loggar in för att slutföra begäran. Administratören uppmanas att godkänna alla behörigheter som du har begärt i scope parametern . Om du använde ett statiskt ( ) värde fungerar det som slutpunkten för v1.0-administratörsmedgivande och begär medgivande för alla omfång som finns i de behörigheter som krävs /.default för appen.

Lyckat svar

Om administratören godkänner behörigheterna för din app ser svaret ut så här:

GET http://localhost/myapp/permissions?tenant=a8990e1f-ff32-408a-9f8e-78d3b9139b95&state=state=12345&admin_consent=True

Felsvar

Om administratören inte godkänner behörigheterna för din app ser det misslyckade svaret ut så här:

GET http://localhost/myapp/permissions?error=permission_denied&error_description=The+admin+canceled+the+request

När du har fått ett lyckat svar från slutpunkten för administratörsmedgivande har appen fått de behörigheter som begärdes. Därefter kan du begära en token för den resurs som du vill använda.

Använda behörigheter

När användaren har gett sitt medgivande till behörigheter för din app kan din app hämta åtkomsttoken som representerar appens behörighet att komma åt en resurs i viss kapacitet. En åtkomsttoken kan bara användas för en enskild resurs. Men kodad i åtkomsttoken är alla behörigheter som din app har beviljats för den resursen. Om du vill hämta en åtkomsttoken kan din app göra en begäran Microsofts identitetsplattform tokenslutpunkt, så här:

POST common/oauth2/v2.0/token HTTP/1.1
Host: https://login.microsoftonline.com
Content-Type: application/json

{
    "grant_type": "authorization_code",
    "client_id": "6731de76-14a6-49ae-97bc-6eba6914391e",
    "scope": "https://outlook.office.com/mail.read https://outlook.office.com/mail.send",
    "code": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...",
    "redirect_uri": "https://localhost/myapp",
    "client_secret": "zc53fwe80980293klaj9823"  // NOTE: Only required for web apps
}

Du kan använda den resulterande åtkomsttoken i HTTP-begäranden till resursen. Den anger på ett tillförlitligt sätt för resursen att din app har rätt behörighet att utföra en viss uppgift.

Mer information om OAuth 2.0-protokollet och hur du hämtar åtkomsttoken finns i Microsofts identitetsplattform slutpunktsprotokollreferensen.

Omfånget /.default

Du kan använda /.default omfånget för att migrera dina appar från v1.0-slutpunkten till Microsofts identitetsplattform slutpunkten. /.defaultOmfånget är inbyggt för varje program som refererar till den statiska listan över behörigheter som konfigurerats för programregistreringen.

Värdet scope är https://graph.microsoft.com/.default funktionellt samma som på resource=https://graph.microsoft.com v1.0-slutpunkten. Genom att ange omfånget i sin begäran begär programmet en åtkomsttoken som innehåller omfång för varje Microsoft Graph-behörighet som du har valt för appen i https://graph.microsoft.com/.default appregistreringsportalen. Omfånget konstrueras med hjälp av resurs-URI och /.default . Så om resurs-URI:en är https://contosoApp.com är det begärda omfånget https://contosoApp.com/.default . Om du måste inkludera ett andra snedstreck för att begära token korrekt kan du läsa avsnittet om avslutande snedstreck.

/.defaultOmfånget kan användas i alla OAuth 2.0-flöden. Men det är nödvändigt i flödet On-Behalf-Of och klientautentiseringsuppgifter. Du behöver den också när du använder slutpunkten för v2-administratörsmedgivande för att begära programbehörigheter.

Klienter kan inte kombinera statiskt ( /.default ) medgivande och dynamiskt medgivande i en enda begäran. Därför scope=https://graph.microsoft.com/.default+mail.read resulterar det i ett fel eftersom det kombinerar omfångstyper.

/.default och medgivande

/.defaultOmfånget utlöser även beteendet för v1.0-slutpunkten. prompt=consent Den begär medgivande för alla behörigheter som programmet har registrerat, oavsett resurs. Om den ingår som en del av begäran returnerar /.default omfånget en token som innehåller omfången för den begärda resursen.

/.default när användaren redan har gett sitt medgivande

/.defaultOmfånget är funktionellt identiskt med beteendet för den resource -centric v1.0-slutpunkten. Den har även medgivandebeteendet för v1.0-slutpunkten. Det vill säga /.default utlöser en fråga om medgivande endast om användaren inte har beviljat någon behörighet mellan klienten och resursen.

Om ett sådant medgivande finns innehåller den returnerade token alla omfång som användaren har beviljats för resursen. Men om ingen behörighet har beviljats eller om parametern har angetts visas en fråga om medgivande för alla omfång som prompt=consent klientprogrammet har registrerat.

Exempel 1: Användaren eller klientadministratören har beviljats behörighet

I det här exemplet har användaren eller en innehavaradministratör mail.read beviljat user.read och Microsoft Graph behörighet till klienten.

Om klienten begär visas ingen fråga om medgivande, oavsett innehållet i klientprogrammets registrerade behörigheter scope=https://graph.microsoft.com/.default för Microsoft Graph. Den returnerade token innehåller omfången mail.read och user.read .

Exempel 2: Användaren har inte beviljats behörighet mellan klienten och resursen

I det här exemplet har användaren inte gett sitt medgivande mellan klienten och Microsoft Graph. Klienten har registrerats för behörigheterna user.read och contacts.read . Den har också registrerats för Azure Key Vault https://vault.azure.net/user_impersonation omfånget .

När klienten begär en token för ser användaren en medgivandesida för omfånget, omfånget och scope=https://graph.microsoft.com/.default user.read Key Vault contacts.read user_impersonation omfattningar. Den returnerade token innehåller endast user.read contacts.read omfången och . Det kan endast användas mot Microsoft Graph.

Exempel 3: Användaren har samtyckt till och klienten begär fler omfång

I det här exemplet har användaren redan samtyckt mail.read till för klienten. Klienten har registrerats för contacts.read omfånget.

När klienten begär en token med hjälp av och begär medgivande via , ser användaren en medgivandesida för alla (och endast) de behörigheter som scope=https://graph.microsoft.com/.default prompt=consent programmet registrerade. contacts.readOmfånget finns på sidan för medgivande men är det mail.read inte. Den token som returneras är för Microsoft Graph. Den innehåller mail.read och contacts.read .

Använda omfånget /.default med klienten

I vissa fall kan en klient begära ett eget /.default omfång. Följande exempel visar det här scenariot.

// Line breaks are for legibility only.

GET https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
response_type=token            //Code or a hybrid flow is also possible here
&client_id=9ada6f8a-6d83-41bc-b169-a306c21527a5
&scope=9ada6f8a-6d83-41bc-b169-a306c21527a5/.default
&redirect_uri=https%3A%2F%2Flocalhost
&state=1234

Det här kodexe exemplet skapar en medgivandesida för alla registrerade behörigheter om föregående beskrivningar av medgivande och /.default gäller för scenariot. Koden returnerar sedan en id_token , i stället för en åtkomsttoken.

Det här beteendet rymmer vissa äldre klienter som flyttar från Azure AD Authentication Library (ADAL) till Microsoft Authentication Library (MSAL). Den här konfigurationen ska inte användas av nya klienter som är mål för Microsofts identitetsplattform.

Klientautentiseringsuppgifter beviljar flöde och /.default

Ett annat sätt att använda är att begära programbehörigheter (eller roller ) i ett icke-interaktivt program, till exempel en daemonapp som använder det flöde för klientautentiseringsuppgifter som beviljar flödet för att anropa /.default ett webb-API.

Information om hur du skapar programbehörigheter (roller) för ett webb-API finns i Lägga till approller i ditt program.

Begäranden om klientautentiseringsuppgifter i klientappen måste innehålla scope={resource}/.default . Här är {resource} webb-API:et som din app har för avsikt att anropa. Att utfärda en begäran om klientautentiseringsuppgifter med hjälp av enskilda programbehörigheter (roller) stöds inte. Alla programbehörigheter (roller) som har beviljats för webb-API:et ingår i den returnerade åtkomsttoken.

Information om hur du beviljar åtkomst till de programbehörigheter som du definierar, inklusive att bevilja administratörsmedgivande för programmet, finns i Konfigurera ett klientprogram för åtkomst till ett webb-API.

Avslutande snedstreck och /.default

Vissa resurs-URI:er har ett avslutande snedstreck, https://contoso.com/ till exempel i stället för https://contoso.com . Det avslutande snedstrecket kan orsaka problem med tokenvalidering. Problem uppstår främst när en token begärs för Azure Resource Manager ( https://management.azure.com/ ). I det här fallet innebär ett avslutande snedstreck på resurs-URI:en att snedstrecket måste finnas när token begärs. Så när du begär en token för https://management.azure.com/ och använder måste du begära /.default https://management.azure.com//.default (observera det dubbla snedstrecket!). Om du i allmänhet kontrollerar att token utfärdas, och om token avvisas av API:et som ska acceptera den, bör du överväga att lägga till ett andra snedstreck och försöka igen.

Felsöka behörigheter och medgivande

Felsökningssteg finns i Oväntat fel när du utför medgivande till ett program.

Nästa steg

• ID-token i Microsofts identitetsplattform
• Åtkomsttoken i Microsofts identitetsplattform