Utvecklarvägledning för villkorsstyrd åtkomst i Microsoft Entra

Funktionen villkorlig åtkomst i Microsoft Entra ID erbjuder ett av flera sätt som du kan använda för att skydda din app och skydda en tjänst. Med villkorsstyrd åtkomst kan utvecklare och företagskunder skydda tjänster på flera olika sätt, bland annat:

• Multifaktorautentisering
• Tillåta att endast Intune-registrerade enheter får åtkomst till specifika tjänster
• Begränsa användarplatser och IP-intervall

Mer information om de fullständiga funktionerna i villkorsstyrd åtkomst finns i artikeln Vad är villkorsstyrd åtkomst?

För utvecklare som skapar appar för Microsoft Entra-ID visar den här artikeln hur du kan använda villkorsstyrd åtkomst och du får också lära dig mer om effekten av att komma åt resurser som du inte har kontroll över som kan ha principer för villkorsstyrd åtkomst tillämpade. Artikeln utforskar också konsekvenserna av villkorsstyrd åtkomst i flödets räkning, webbappar, åtkomst till Microsoft Graph och anropande API:er.

Kunskap om appar med en och flera klientorganisationer och vanliga autentiseringsmönster förutsätts .

Hur påverkar villkorsstyrd åtkomst en app?

Apptyper som påverkas

I de vanligaste fallen ändrar inte villkorsstyrd åtkomst appens beteende eller kräver ändringar från utvecklaren. Endast i vissa fall när en app indirekt eller tyst begär en token för en tjänst, kräver en app kodändringar för att hantera utmaningar med villkorsstyrd åtkomst. Det kan vara så enkelt som att utföra en interaktiv inloggningsbegäran.

Mer specifikt kräver följande scenarier kod för att hantera utmaningar med villkorsstyrd åtkomst:

• Appar som utför flödets räkning
• Appar som har åtkomst till flera tjänster/resurser
• Ensidesappar med MSAL.js
• Web Apps anropar en resurs

Principer för villkorsstyrd åtkomst kan tillämpas på appen, men kan även tillämpas på ett webb-API som appen har åtkomst till. Mer information om hur du konfigurerar en princip för villkorsstyrd åtkomst finns i Snabbstart: Kräv MFA för specifika appar med villkorsstyrd åtkomst i Microsoft Entra.

Beroende på scenariot kan en företagskund tillämpa och ta bort principer för villkorsstyrd åtkomst när som helst. Implementera utmaningshantering för att appen ska fortsätta att fungera när en ny princip tillämpas. Följande exempel illustrerar utmaningshantering.

Exempel på villkorsstyrd åtkomst

Vissa scenarier kräver kodändringar för att hantera villkorsstyrd åtkomst medan andra fungerar som de är. Här följer några scenarier som använder villkorsstyrd åtkomst för att utföra multifaktorautentisering som ger viss insikt i skillnaden.

• Du skapar en iOS-app med en enda klientorganisation och tillämpar en princip för villkorsstyrd åtkomst. Appen loggar in en användare och begär inte åtkomst till ett API. När användaren loggar in anropas principen automatiskt och användaren måste utföra multifaktorautentisering (MFA).
• Du skapar en intern app som använder en mellannivåtjänst för att få åtkomst till ett underordnade API. En företagskund på företaget som använder den här appen tillämpar en princip på det underordnade API:et. När en slutanvändare loggar in begär den inbyggda appen åtkomst till mellannivån och skickar token. Mellannivån utför ett flöde för att begära åtkomst till det underordnade API:et. I det här läget presenteras en "utmaning" för anspråk på mellannivån. Mellannivån skickar tillbaka utmaningen till den interna appen, som måste följa principen för villkorsstyrd åtkomst.

Microsoft Graph

Microsoft Graph har särskilda överväganden när du skapar appar i miljöer med villkorsstyrd åtkomst. I allmänhet fungerar mekaniken för villkorsstyrd åtkomst på samma sätt, men de principer som användarna ser baseras på underliggande data som appen begär från diagrammet.

Mer specifikt representerar alla Microsoft Graph-omfång vissa datauppsättningar som kan tillämpas individuellt. Eftersom principer för villkorsstyrd åtkomst tilldelas specifika datauppsättningar tillämpar Microsoft Entra-ID principer för villkorsstyrd åtkomst baserat på data bakom Graph – i stället för själva Graph.

Om en app till exempel begär följande Microsoft Graph-omfång

scopes="ChannelMessages.Read.All Mail.Read"

En app kan förvänta sig att användarna uppfyller alla principer som har angetts i Teams och Exchange. Vissa omfång kan mappas till flera datauppsättningar om de ger åtkomst.

Följa en princip för villkorsstyrd åtkomst

För flera olika apptopologier utvärderas en princip för villkorsstyrd åtkomst när sessionen upprättas. När en princip för villkorsstyrd åtkomst fungerar på kornigheten för appar och tjänster beror den punkt där den anropas mycket på det scenario som du försöker utföra.

När appen försöker komma åt en tjänst med en princip för villkorsstyrd åtkomst kan det uppstå en utmaning för villkorlig åtkomst. Den här utmaningen är kodad i parametern claims som kommer i ett svar från Microsoft Entra ID. Här är ett exempel på den här utmaningsparametern:

claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Utvecklare kan ta den här utmaningen och lägga till den i en ny begäran i Microsoft Entra-ID. Genom att skicka det här tillståndet uppmanas slutanvändaren att utföra alla åtgärder som krävs för att följa principen för villkorsstyrd åtkomst. I följande scenarier förklaras detaljer om felet och hur du extraherar parametern.

Scenarier

Förutsättningar

Microsoft Entra Villkorlig åtkomst är en funktion som ingår i Microsoft Entra ID P1 eller P2. Kunder med Microsoft 365 Business-licenser har också åtkomst till funktioner för villkorsstyrd åtkomst.

Överväganden för specifika scenarier

Följande information gäller endast i dessa scenarier för villkorsstyrd åtkomst:

• Appar som utför flödets räkning
• Appar som har åtkomst till flera tjänster/resurser
• Ensidesappar med MSAL.js

I följande avsnitt beskrivs vanliga scenarier som är mer komplexa. Den grundläggande driftsprincipen är principer för villkorsstyrd åtkomst utvärderas när token begärs för den tjänst som har en princip för villkorsstyrd åtkomst tillämpad.

Scenario: App som utför on-behalf-of-flödet

I det här scenariot går vi igenom det fall där en intern app anropar en webbtjänst/API. I sin tur gör den här tjänsten flödet "å uppdrag för" för att anropa en underordnad tjänst. I vårt fall har vi tillämpat vår princip för villkorsstyrd åtkomst på den underordnade tjänsten (Webb-API 2) och använder en intern app i stället för en server/daemon-app.

Den första tokenbegäran för Webb-API 1 uppmanar inte slutanvändaren om multifaktorautentisering eftersom webb-API 1 kanske inte alltid når det underordnade API:et. När webb-API 1 försöker begära en token för användarens räkning för Webb-API 2 misslyckas begäran eftersom användaren inte har loggat in med multifaktorautentisering.

Microsoft Entra ID returnerar ett HTTP-svar med intressanta data:

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API 2 App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

I Webb-API 1 får vi felet error=interaction_requiredoch skickar tillbaka claims utmaningen till skrivbordsappen. Då kan skrivbordsappen göra ett nytt acquireToken() anrop och lägga till claimsutmaningen som en extra frågesträngsparameter. Den här nya begäran kräver att användaren utför multifaktorautentisering och sedan skickar den nya token tillbaka till Webb-API 1 och slutför flödets räkning.

Om du vill prova det här scenariot kan du läsa vårt .NET-kodexempel. Den visar hur du skickar tillbaka anspråksutmaningen från Webb-API 1 till den interna appen och skapar en ny begäran i klientappen.

Scenario: Appåtkomst till flera tjänster

I det här scenariot går vi igenom det fall där en webbapp har åtkomst till två tjänster, varav en har tilldelats en princip för villkorsstyrd åtkomst. Beroende på applogik kan det finnas en sökväg där appen inte kräver åtkomst till båda webbtjänsterna. I det här scenariot spelar den ordning i vilken du begär en token en viktig roll i slutanvändarupplevelsen.

Anta att webbtjänsten A och B och webbtjänsten B har vår princip för villkorsstyrd åtkomst tillämpad. Den första interaktiva autentiseringsbegäran kräver medgivande för båda tjänsterna, men principen för villkorsstyrd åtkomst krävs inte i alla fall. Om appen begär en token för webbtjänsten B anropas principen och efterföljande begäranden för webbtjänsten A lyckas också på följande sätt.

Om appen först begär en token för webbtjänsten A anropar inte slutanvändaren principen för villkorsstyrd åtkomst. Detta gör att apputvecklaren kan styra slutanvändarupplevelsen och inte tvinga principen för villkorsstyrd åtkomst att anropas i alla fall. Det svåra fallet är om appen senare begär en token för webbtjänsten B. I det här läget måste slutanvändaren följa principen för villkorsstyrd åtkomst. När appen försöker acquireTokenkan det generera följande fel (illustreras i följande diagram):

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Om appen använder MSAL-biblioteket görs alltid ett nytt försök att hämta token interaktivt. När den här interaktiva begäran inträffar har slutanvändaren möjlighet att följa den villkorliga åtkomsten. Detta är sant om inte begäran är en AcquireTokenSilentAsync eller PromptBehavior.Never i vilket fall appen behöver utföra en interaktiv AcquireToken begäran för att ge slutanvändaren möjlighet att följa principen.

Scenario: Ensidesapp (SPA) med MSAL.js

I det här scenariot går vi igenom fallet när vi har en ensidesapp (SPA) som anropar ett villkorligt åtkomstskyddat webb-API med hjälp av MSAL.js. Det här är en enkel arkitektur men har vissa nyanser som måste beaktas när du utvecklar kring villkorsstyrd åtkomst.

I MSAL.js finns det några funktioner som hämtar token: acquireTokenSilent(), acquireTokenPopup()och acquireTokenRedirect().

• acquireTokenSilent() kan användas för att tyst hämta en åtkomsttoken, vilket innebär att det inte visar användargränssnittet under några omständigheter.
• acquireTokenPopup() och acquireTokenRedirect() används båda för att interaktivt begära en token för en resurs, vilket innebär att de alltid visar inloggningsgränssnittet.

När en app behöver en åtkomsttoken för att anropa ett webb-API försöker den använda en acquireTokenSilent(). Om token har upphört att gälla eller om vi behöver följa en princip för villkorsstyrd åtkomst misslyckas funktionen acquireToken och appen använder acquireTokenPopup() eller acquireTokenRedirect().

Nu ska vi gå igenom ett exempel med vårt scenario för villkorsstyrd åtkomst. Slutanvändaren landade precis på webbplatsen och har ingen session. Vi utför ett loginPopup() anrop och hämtar en ID-token utan multifaktorautentisering. Sedan trycker användaren på en knapp som kräver att appen begär data från ett webb-API. Appen försöker göra ett acquireTokenSilent() anrop men misslyckas eftersom användaren inte har utfört multifaktorautentisering ännu och måste följa principen för villkorsstyrd åtkomst.

Microsoft Entra-ID skickar tillbaka följande HTTP-svar:

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.

Vår app måste fånga error=interaction_required. Programmet kan sedan använda antingen acquireTokenPopup() eller acquireTokenRedirect() på samma resurs. Användaren tvingas utföra en multifaktorautentisering. När användaren har slutfört multifaktorautentiseringen utfärdas appen en ny åtkomsttoken för den begärda resursen.

Om du vill prova det här scenariot kan du läsa vårt React SPA-anrop Node.js webb-API med hjälp av flödeskodexempel för räkning. Det här kodexemplet använder principen för villkorsstyrd åtkomst och webb-API:et som du registrerade tidigare med ett React SPA för att demonstrera det här scenariot. Den visar hur du hanterar anspråksutmaningen korrekt och får en åtkomsttoken som kan användas för ditt webb-API.

Se även

• Mer information om funktionerna finns i Villkorlig åtkomst i Microsoft Entra-ID.
• Fler Microsoft Entra-kodexempel finns i exempel.
• Mer information om MSAL SDK:er och åtkomst till referensdokumentationen finns i översikten över Microsoft Authentication Library.
• Mer information om scenarier med flera klientorganisationer finns i Så här loggar du in användare med hjälp av multitenantmönstret.
• Läs mer om villkorlig åtkomst och skydd av åtkomst till IoT-appar.