Auktorisera program, resurser och arbetsbelastningar med Microsoft Entra-ID

I den här artikeln diskuterar vi auktorisering när en enskild människa interagerar med och dirigerar ett program, när API(Application Programming Interfaces) agerar för en användare. Vi tar även upp när program eller tjänster fungerar oberoende av varandra. Det är den fjärde i en serie artiklar om hur oberoende programvaruutvecklare (ISV:er) kan skapa och optimera sina program för Microsoft Entra-ID. I den här serien kan du lära dig mer om följande ämnen:

Auktorisering i program

I det här avsnittet går vi igenom scenarier där en enskild människa interagerar med och dirigerar ett program. I avsnittet Auktorisering i resurser (API:er) beskrivs hur API:er utför auktorisering när användaren behöver auktorisering för att få åtkomst till en resurs, men Microsoft Entra-ID utför inte den slutliga auktoriseringen. Avsnittet Auktorisering i arbetsbelastningar beskriver scenarier där program eller tjänster fungerar oberoende av varandra.

Program kräver följande auktoriseringar när de behöver komma åt resurser för en användare.

  • Programmet måste ha behörighet att komma åt specifika åtgärder inom specifika resurser för den aktuella användaren.
  • Användaren måste ha behörighet att komma åt en resurs under de aktuella villkoren.
  • Användaren måste ha behörighet att komma åt en resurs.

Auktoriseringsprocessen börjar med ett program som använder OAuth 2.0 för att begära en åtkomsttoken från Microsoft Entra-ID för att få åtkomst till specifika åtgärder inom en specifik resurs för användaren. I delegerad åtkomst fungerar en app som ett ombud för användaren.

För utvecklare kan en resurs vara ett API som Microsoft Graph, Azure Storage eller ett eget API. De flesta API:er har dock olika åtgärder, till exempel läsning och skrivning. När ett program bara läser från ett API ska en app endast ha auktorisering för läsåtgärder. Den här metoden skyddar ett program från att komprometteras och användas för mer åtkomst än vad utvecklaren avsåg. Utvecklaren följer principen om lägsta behörighet när deras program endast auktoriserar för de åtgärder som krävs.

För att ange vilka specifika åtgärder i ett specifikt API som ett program kräver använder utvecklare omfångsparametern för en OAuth 2.0-begäran. API-designern publicerar de omfång som ett program kan begära som en del av API:ets appregistrering. Microsoft Power BI-tjänst omfång innehåller till exempel följande.

Power BI-tjänst omfång Operativa åtgärder
https://analysis.windows.net/powerbi/api/Capacity.Read.All Appen kan visa alla Power BI Premium- och Power BI Embedded-kapaciteter som den inloggade användaren har åtkomst till.
https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All Appen kan visa och redigera alla Power BI Premium- och Power BI Embedded-kapaciteter som den inloggade användaren har åtkomst till.

Om ett program bara läser kapaciteter begär appen omfånget https://analysis.windows.net/powerbi/api/Capacity.Read.All . Om ett program redigerar kapacitet begär appen omfånget https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All .

Omfånget innehåller API:ets identitet och åtgärdens identitet. I omfånget https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All är https://analysis.windows.net/powerbi/apiAPI:et . Operationen är Capacity.ReadWrite.All. Med tanke på microsoft graph-API:ets breda räckvidd och popularitet kan utvecklare begära omfång för Microsoft Graph utan omfångets API-komponent. Till exempel definierar Microsoft Graph ett omfång https://graph.microsoft.com/Files.Read som program kan begära med Files.Read i stället för att använda det fullständiga omfångsnamnet.

För att slutföra den första auktoriseringen måste ett program ha behörighet att komma åt specifika åtgärder inom specifika resurser för den aktuella användaren. Microsoft Entra-ID måste först autentisera den aktuella användaren. Enkel inloggning (SSO) kan uppfylla den här autentiseringen eller kräva ny användarinteraktion.

När Microsoft Entra-ID:t har fastställt användaren kontrollerar den om användaren har godkänt programmet för det begärda omfånget. Den här processen kallas för att bevilja medgivande. Om användaren har gett sitt medgivande kan auktoriseringsprocessen fortsätta. Med administratörsmedgivande kan administratörsanvändare samtycka för sig själva och för hela organisationen. Microsoft Entra-ID kontrollerar om programmet har administratörsmedgivande för ett omfång. Om det beviljas fortsätter auktoriseringsprocessen.

Under omfångsdesignen kan en API-designer ange omfång som endast en administratör kan godkänna. Omfång som kräver administratörsmedgivande representerar åtgärder som API-designern anser vara känsligare, kraftfullare eller i stort sett tillräckligt komplicerade för att en icke-administratörsanvändare inte ska ha behörighet att bevilja ett program.

API-designers har första ordet i vilka av deras omfång som kräver administratörsmedgivande, men de har inte sista ordet. När en API-designer anger att ett omfång kräver administratörsmedgivande kräver omfånget alltid administratörsmedgivande. För omfång som API-designern inte anger som kräver administratörsmedgivande kan klientadministratören kräva administratörsmedgivande eller riskbaserat stegvisa medgivande kan fastställa krav på administratörsmedgivande. Utvecklare kan inte förutsäga om en tokenbegäran kräver administratörsmedgivande. Den här begränsningen påverkar dock inte den kod som behövs. Medgivandenek är bara en av många orsaker till att tokenbegäran nekas. Applikationer måste alltid smidigt hantera att inte ta emot en token.

Om användaren eller administratören inte har beviljat medgivande ser användaren en uppmaning om medgivande enligt följande exempel.

Skärmbild av uppmaning om användarmedgivande.

Uppmaningar om administratörsanvändares medgivande kan göra det möjligt för dem att välja Medgivande för din organisations räkning för att bevilja medgivande för alla användare i klientorganisationen enligt följande exempel.

Skärmbild av uppmaningen om administratörsmedgivande.

Program styr tidpunkten för frågor om användarmedgivande. Microsoft Entra-ID stöder statiskt medgivande: när ett program använder omfånget .default begär appen alla behörigheter som deklareras i appens registrering. Med statiskt medgivande begär din app i förväg alla behörigheter som den kan behöva.

Statiskt medgivande kan avskräcka användare och administratörer från att godkänna appens åtkomstbegäran. Bästa praxis för processen för medgivandebegäran är att begära nödvändiga behörigheter dynamiskt för baslinjefunktionerna i ditt program vid start av programmet och begära fler omfång när det behövs. Begär inkrementellt fler omfång när programmet utför åtgärder som kräver dessa omfång. Den här metoden ger användaren en bättre förståelse för andra behörigheter som korrelerar med tidsinställningen för funktioner. För varje API-åtkomsttoken innehåller Microsoft Entra-ID alla omfång som tidigare beviljats till ett program och inte bara omfången i begäran.

Ett program kan till exempel begära https://graph.microsoft.com/user.read att logga in användaren och komma åt användarens profil när programmet startar. Senare väljer en användare att Spara till OneDrive och begär programmet https://graph.microsoft.com/files.readwrite att skriva en fil till användarens OneDrive. Eftersom användaren ser varför en app ber om att skriva till sin OneDrive beviljar användaren behörigheten och appen sparar en fil i användarens OneDrive. Användaren stänger sedan appen. Nästa gång appen startas, begär den https://graph.microsoft.com/user.read. Microsoft Entra-ID returnerar en åtkomsttoken med https://graph.microsoft.com/user.read och https://graph.microsoft.com/files.readwrite omfång. En tokenbegäran för omfånget https://graph.microsoft.com/files.readwrite kräver inte medgivande eftersom användaren har beviljat den. Cachelagring av token i Microsoft Authentication Libraries (MSAL) hanterar automatiskt cachelagring av token baserat på de beviljade behörigheterna. Efter omstarten av appen returnerar anrop till MSAL för att hämta en token med omfattningen https://graph.microsoft.com/files.readwrite den token som cachelagrats från appens första begäran med omfattningen https://graph.microsoft.com/user.read. Ett annat anrop till Microsoft Entra-ID är onödigt.

Dynamiskt och inkrementellt medgivande kräver inga deklarerade behörigheter under programregistreringen. Vi rekommenderar dock starkt att program deklarerar alla behörigheter som ett program kan kräva i en appregistrering för att stödja statiskt medgivande. Administratörer kan bevilja administratörsmedgivande i administrationscentret för Microsoft Entra med hjälp av Microsoft Graph PowerShell eller med Microsoft Graph-API:et.

För att bevilja administratörsmedgivande för ett program använder administrationscentret för Microsoft Entra statiskt medgivande genom att begära medgivande med omfånget .default för en app. Administratörer kan inte bevilja administratörsmedgivande i administrationscentret för Microsoft Entra till appar som kräver behörighet om utvecklare inte deklarerar dem i appregistrering.

Microsoft Entra-ID-kunder kan använda principer för villkorsstyrd åtkomst för att skydda resurser (API:er) och webbläsarbaserade program. Som standard kan administratörer inte tillämpa principer för villkorsstyrd åtkomst på inbyggda appautentiseringar. Klientadministratörer kan rikta in sig på Alla resurser (tidigare "Alla molnappar") eller använda anpassade säkerhetsattribut för att rikta in sig på interna appar med principer för villkorsstyrd åtkomst. Även om principen tillämpas på annat sätt inkluderar den inte vissa appar som har åtkomst till Microsoft Graph eller Azure AD Graph.

Program kräver vanligtvis inte särskild kod för villkorsstyrd åtkomst om inte följande scenarier gäller.

  • Appar som utför flödets räkning
  • Appar som har åtkomst till flera tjänster eller resurser
  • Ensidesappar som använder MSAL.js
  • Webbappar som anropar en resurs

Om din app implementerar något av dessa scenarier kan du läsa Utvecklarvägledning för villkorsstyrd åtkomst i Microsoft Entra.

Kostnadsfria Microsoft Entra-ID-klienter kan inte använda villkorsstyrd åtkomst (se licensieringskrav. Företagets produktionsklientorganisation kan ha den licensiering som krävs. Utvärdera dessa villkor innan du använder produktionsmiljön för testning. Det finns vägledning för att skapa en testhyresgäst.

Som standard gäller principer för villkorsstyrd åtkomst för program och de resurser som en app har åtkomst till på appnivå. IT-administratörer kan tillämpa principer på appnivå för alla appar utan att utvecklarna deltar. Vissa program och scenarier kräver mer kornighet. En ekonomiapp kan till exempel kräva multifaktorautentisering för vanlig användning. En transaktion över ett angivet belopp kan dock kräva en hanterad enhet. Utvecklare kan göra det möjligt för IT-administratörer att tilldela stegvisa principer för villkorsstyrd åtkomst till olika områden i ett program genom att implementera kontexten för autentisering med villkorsstyrd åtkomst. Utvecklarguiden för autentiseringskontext för villkorsstyrd åtkomst är en bra referens för dessa funktioner.

Som standard utfärdar Microsoft Entra-ID åtkomsttoken som är giltiga under en viss tid. Program måste aldrig anta livslängd. De måste använda parametern expires_in som Microsoft Entra-ID returnerar med åtkomsttoken. MSAL hanterar automatiskt det här scenariot. Under åtkomsttokens livslängd har användaren behörighet att komma åt resursen under villkoren vid tidpunkten för auktoriseringen.

Fördröjningen mellan när villkoren ändras och när tillämpningen av principändringar inträffar kan gälla administratörer och användare. När en användare till exempel förlorar en enhet kan IT-administratören återkalla användarens sessioner. En app på den förlorade enheten kan dock fortsätta att komma åt Microsoft Graph för användaren tills token upphör att gälla. Microsofts utvärdering av kontinuerlig åtkomst (CAE) kan förhindra åtkomst efter återkallande av användarsessioner för program som antar CAE. Om ditt program anropar Microsoft Graph minst en gång i timmen kan du använda CAE. Hur du använder API:er för kontinuerlig åtkomstutvärdering i dina program innehåller implementeringsinformation.

Om du inte kan bygga på MSAL måste appen använda OAuth 2.0 för att begära åtkomsttoken från Microsoft Entra-ID. Microsofts identitetsplattform- och OAuth 2.0-auktoriseringskodflödet innehåller implementeringsinformation för de flöden som Microsoft Entra ID stöder.

Om du skapar mobilappar, läs Stöd för SSO och appskyddspolicyr dina i mobilappar. Lär dig att stödja tokenförvärv, Intune-hantering av mobilprogram (MAM) och appskyddsprinciper.

Auktorisering i resurser (API:er)

I avsnittet Auktorisering i program introducerades tre nödvändiga auktoriseringar när program behöver komma åt resurser för en användare men bara täckte de två första. Användaren måste ha behörighet att komma åt en resurs, men Microsoft Entra-ID utför inte den slutliga auktoriseringen. Resursen (API) utför auktoriseringen.

API:er måste framtvinga två auktoriseringar när de agerar för en användare:

  • API:er måste auktorisera en app för att anropa API:et. Kontrollera att åtkomsttokens scp anspråk (omfång) innehåller det nödvändiga omfånget.
  • API:er måste ge användaren behörighet att komma åt den specifika resursen. Anspråken oid (objekt-ID) och sub (ämne) i token representerar användaridentiteten.

Vi rekommenderar oid och sub krav för auktorisering.

Microsoft Entra ID implementerar ett parvis sub anspråk, därför är anspråket sub en unik användaridentifierare för den begärande appen. Samma användare som använder en annan app har ett annat sub anspråk. Anspråket oid är konstant för användaren i alla appar.

Applikationer tillhandahåller den nödvändiga åtkomsttoken till API:er som Microsoft Entra ID skyddar i auktoriseringshuvudet för begäran http som en bärartoken. API:er måste verifiera den mottagna token fullständigt eftersom token inte kommer direkt från Microsoft Entra-ID. Betrakta den anropande appen som opålitlig tills tokenvalidering. Referensartiklarna åtkomsttokenreferens och valideringsreferens för anspråk ger detaljer om hur du validerar åtkomsttoken för Microsoft Entra ID.

Microsoft Entra-ID publicerar de offentliga nycklar som API:er använder för att verifiera tokens signatur. Dessa nycklar rullas över regelbundet och när situationen kräver offentlig nyckelåterställning. Programmet får aldrig anta ett angivet schema för offentlig nyckelrotation. Signeringsnyckelns rollover i Microsofts identitetsplattform förklarar hur du hanterar offentligt nyckelbyte korrekt.

Vi rekommenderar att du använder ett väl underhållet bibliotek för att utföra tokenverifiering. Om du skapar en webbapp eller ett API på ASP.NET eller ASP.NET Core använder Microsoft.Identity.Web du för att hantera tokenverifiering. Instruktionsartikeln skyddat webb-API förklarar hur du använder Microsoft.Identity.Web för att skydda ett API.

API:er måste ibland anropa andra API:er. När en app fungerar för användaren får API:et en delegerad åtkomsttoken som innehåller den aktuella användarens identitet. Det är viktigt att API:et endast litar på en validerad token från Microsoft Entra-ID för att fastställa den aktuella användarens identitet. Den här metoden förhindrar att programmet komprometterar så att användare personifierar andra användare och får åtkomst till resurser för en annan användare. För samma skydd när ett API anropar ett annat API använder du flödet Å uppdrag av OAuth för att hämta en åtkomsttoken för att anropa ett API för den användare som API:et anropades för. Skapa ett webb-API som anropar webb-API:er innehåller steg för ett API för att anropa andra API:er för den aktuella appanvändaren.

Förutom delegerad åtkomst kan API:er behöva stödja program och agera oberoende utan aktuella användare. Microsoft Entra-ID refererar till dessa program som arbetsbelastningar. API:er använder inte anspråket scp (omfång) för att framtvinga arbetsbelastningsauktorisering. API använder i stället anspråket roles för att verifiera att arbetsuppgiften har det nödvändiga medgivandet. API:er ansvarar för att framtvinga att arbetsbelastningen har behörighet att komma åt resursen.

Auktorisering i arbetsbelastningar

Arbetsbelastningar är program som fungerar oberoende av varandra och inte har någon aktuell användare. Precis som delegerad åtkomst som beskrivs i avsnittet Auktorisering i program kräver appåtkomst flera auktoriseringar:

  • Programmet måste ha behörighet att komma åt specifika åtgärder inom specifika resurser.
  • Programmet måste ha behörighet att komma åt resursen under de aktuella villkoren.
  • Programmet måste ha behörighet att komma åt resursen.

Processen börjar med att ett arbetsflöde begär en åtkomsttoken med omfånget .default (till exempel https://graph.microsoft.com/.default). Till skillnad från delegerad åtkomst (program kan dynamiskt och inkrementellt begära omfång) måste arbetslaster alltid använda statiskt medgivande och omfånget .default.

API-designers skapar appbehörigheter för sitt API genom att lägga till roller i API:ets appregistrering. Dessa roller har en tillåten medlemstyp av applikationer som tillåter rolltilldelning till arbetslaster. Tilldela roller till arbetsbelastningar i administrationscentret för Microsoft Entra eller med Microsoft Graph. I adminportalen för Microsoft Entra krävs administratörsmedgivande för de tilldelade rollerna innan arbetsbördan kan köras.

Som standard ger en appbehörighet arbetsbelastningarna åtkomst till alla instanser av en resurs. Till exempelhttps://graph.microsoft.com/user.read.all tillåter en tjänst att få åtkomst till den fullständiga användarprofilen för varje användare i klientorganisationen. IT-administratörer är ofta ovilliga att bevilja dessa breda behörigheter.

För arbetsbelastningar som har åtkomst till Microsoft Graph använder du dessa metoder för att begränsa programbehörigheten:

Till skillnad från applikationer med användare autentiseras arbetsbelastningar mot Microsoft Entra-ID.

För arbetsbelastningar som körs i Microsoft Azure är den bästa metoden för en arbetsbelastning att autentisera sig själv hanterade identiteter för Azure-resurser. Funktionen hanterade identiteter tar bort behovet av att hantera autentiseringsuppgifter för arbetsbelastningen. Det finns inga tillgängliga autentiseringsuppgifter. Microsoft Entra ID hanterar fullständigt autentiseringsuppgifter. Utan autentiseringsuppgifter att hantera riskerar inga autentiseringsuppgifter att komprometteras.

Med ökad säkerhet ökar även hanterade identiteter återhämtning. Hanterade identiteter använder långlivade åtkomsttoken och information från Microsoft Entra-ID för att hämta nya token innan token upphör att gälla. Hanterade identiteter använder regionala slutpunkter som hjälper till att förhindra fel som inte är regionbaserade genom att konsolidera tjänstberoenden. Regionala slutpunkter hjälper till att hålla trafiken i ett geografiskt område. Om din Azure-resurs till exempel finns i WestUS2 stannar all trafik i WestUS2.

Om arbetsbelastningen inte körs i Microsoft Azure måste arbetsbelastningen autentisera sig med OAuth 2.0-klientautentiseringsflödet.

Microsoft Entra ID stöder följande typer av klientautentiseringsuppgifter:

  • Certifikat. Arbetsbelastningar bevisar att de har tillgång till en privat nyckel genom att signera ett intyg med den privata nyckeln. Den privata nyckeln överförs inte till Microsoft Entra-ID. Endast försäkran skickas. Vi rekommenderar certifikat i stället för klienthemligheter eftersom de är säkrare och ofta bättre hanterade.
  • Federerade autentiseringsuppgifter. Med arbetsbelastningsidentitetsfederation kan arbetsbelastningar som inte körs på Microsoft Azure använda en identitet från en annan identitetsprovider, GitHub Actions eller Kubernetes-kluster. Arbetsbelastningar begär token på samma sätt för federerade autentiseringsuppgifter som för certifikatautentiseringsuppgifter. Skillnaden är att försäkran, en signerad JSON-webbtoken, kommer från federationsidentitetsprovidern.
  • Klienthemlighet. En klienthemlighet, ibland kallad ett programlösenord, är ett strängvärde som en arbetslast kan använda för att identifiera sig själv. Textvärdet för hemligheten skickas från arbetslasten till Microsoft Entra ID i en POST-begäran för en token. Klienthemligheter är mindre säkra än certifikat eller federering av arbetsbelastningsidentiteter. Om din arbetsbelastning använder känsliga data följer du dessa bästa praxis för hantering av känsliga data.

Förutom Microsoft Entra-ID innehåller Microsoft Entra-produktfamiljen Microsoft Entra-arbetsbelastnings-ID. Microsoft Entra Workload ID har följande premiumfunktioner för att förbättra arbetsbelastningssäkerheten.

  • Villkorlig åtkomst stöder plats- eller riskbaserade principer för arbetsbelastningsidentiteter.
  • Microsoft Entra ID Protection innehåller rapporter om komprometterade autentiseringsuppgifter, avvikande inloggningar och misstänkta ändringar av konton.
  • Åtkomstgranskningar möjliggör granskningsdelegering till rätt personer, med fokus på de viktigaste privilegierade rollerna.
  • Rekommendationer för apphälsa föreslår sätt att hantera brister i identitetshygienen i din programportfölj och förbättra säkerheten och motståndskraften hos klientorganisationen.

Arbetslaster kan stödja kontinuerlig åtkomstutvärdering (CAE) förutsatt att de anropar Microsoft Graph minst en gång per timme. För att stödja CAE måste arbetsbelastningen vara en enklientapplikation och appen vara registrerad i klienten där den har åtkomst till Microsoft Graph. Om din arbetsbelastning uppfyller dessa krav kan du läsa det här exemplet för implementeringssteg.

Nästa steg

  • Last updated on