Dela via

Programtyper som kan användas i Active Directory B2C

Viktigt!

Från och med den 1 maj 2025 är Azure AD B2C inte längre tillgängligt att köpa för nya kunder. Läs mer i våra vanliga frågor och svar.

Azure Active Directory B2C (Azure AD B2C) stöder autentisering för olika moderna programarkitekturer. Alla baseras på branschstandardprotokollen OAuth 2.0 eller OpenID Connect. Den här artikeln beskriver de typer av program som du kan skapa, oberoende av det språk eller den plattform du föredrar. Det hjälper dig också att förstå scenarier på hög nivå innan du börjar skapa program.

Varje program som använder Azure AD B2C måste registreras i din Azure AD B2C-klientorganisation med hjälp av Azure-portalen. Programregistreringsprocessen samlar in och tilldelar värden, till exempel:

  • Ett program-ID som unikt identifierar ditt program.
  • En svars-URL som kan användas för att dirigera tillbaka svar till ditt program.

Varje begäran som skickas till Azure AD B2C anger ett användarflöde (en inbyggd princip) eller en anpassad princip som styr beteendet för Azure AD B2C. Med båda principtyperna kan du skapa en mycket anpassningsbar uppsättning användarupplevelser.

Interaktionen mellan varje program följer ett liknande mönster på hög nivå:

  1. Programmet dirigerar användaren till v2.0-slutpunkten för att köra en policy.
  2. Användaren slutför policyn enligt policydefinitionen.
  3. Programmet tar emot en säkerhetstoken från v2.0-slutpunkten.
  4. Programmet använder säkerhetstoken för att komma åt skyddad information eller en skyddad resurs.
  5. Resursservern verifierar säkerhetstoken för att verifiera att åtkomst kan beviljas.
  6. Programmet uppdaterar regelbundet säkerhetstoken.

De här stegen kan skilja sig något beroende på vilken typ av program du skapar.

Webbapplikationer

För webbprogram (inklusive .NET, PHP, Java, Ruby, Python och Node.js) som finns på en webbserver och nås via en webbläsare, stöder Azure AD B2C OpenID Connect för alla användarupplevelser. I Azure AD B2C-implementeringen av OpenID Connect initierar webbprogrammet användarupplevelser genom att utfärda autentiseringsbegäranden till Microsoft Entra-ID. Resultatet av begäran är en id_token. Den här säkerhetstoken representerar användarens identitet. Den innehåller också information om användaren i form av anspråk:

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

Läs mer om vilka typer av token och anspråk som är tillgängliga för ett program i azure AD B2C-tokenreferensen.

I en webbapplikation tar varje körning av en policy följande övergripande steg:

  1. Användaren bläddrar till webbprogrammet.
  2. Webbprogrammet omdirigerar användaren till Azure AD B2C som anger vilken princip som ska köras.
  3. Användaren slutför policyn.
  4. Azure AD B2C returnerar en id_token till webbläsaren.
  5. id_token skickas till omdirigerings-URI:n.
  6. id_token Verifieras och en sessionscookie har angetts.
  7. En säker sida returneras till användaren.

Validering av id_token med hjälp av en offentlig signeringsnyckel som tas emot från Microsoft Entra-ID räcker för att verifiera användarens identitet. Den här processen anger också en sessionscookie som kan användas för att identifiera användaren vid efterföljande sidbegäranden.

Om du vill se det här scenariot i praktiken kan du prova något av kodexemplen för webbprograminloggning i avsnittet Komma igång.

Förutom att underlätta enkel inloggning kan ett webbprogram också behöva komma åt en serverdelswebbtjänst. I det här fallet kan webbprogrammet utföra ett något annorlunda OpenID Connect-flöde och hämta token med hjälp av auktoriseringskoder och uppdateringstoken. Det här scenariot visas i den följande webb-API-sektionen.

Enkelsidesapplikationer

Många moderna webbprogram skapas som enkelsidiga program på klientsidan ("SPAs"). Utvecklare skriver dem med hjälp av JavaScript eller ett SPA-ramverk som Angular, Vue eller React. Dessa program körs i en webbläsare och har andra autentiseringsegenskaper än traditionella webbprogram på serversidan.

Azure AD B2C innehåller två alternativ för att aktivera ensidesprogram för att logga in användare och få token för åtkomst till serverdelstjänster eller webb-API:er:

Auktoriseringskodflöde (med PKCE)

Med OAuth 2.0-auktoriseringskodflödet (med PKCE) kan programmet utbyta en auktoriseringskod för ID-token för att representera de autentiserade användar - och åtkomsttoken som krävs för att anropa skyddade API:er. Dessutom returneras uppdateringstoken som ger långsiktig åtkomst till resurser för användarnas räkning utan att kräva interaktion med dessa användare.

Vi rekommenderar den här metoden. Att ha uppdateringstoken med begränsad livslängd hjälper ditt program att anpassa sig till moderna begränsningar för webbläsarens cookiesekretess, till exempel Safari ITP.

Om du vill dra nytta av det här flödet kan ditt program använda ett autentiseringsbibliotek som stöder det, till exempelMSAL.js 2.x.

Autentisering med enkeltsideapplikationer

Implicit beviljandeflöde

Vissa bibliotek, till exempel MSAL.js 1.x, stöder bara implicit beviljandeflöde eller så implementeras ditt program för att använda implicit flöde. I dessa fall stöder Azure AD B2C implicit OAuth 2.0-flödet. Det implicita beviljandeflödet gör att programmet kan hämta ID och åtkomsttoken . Till skillnad från auktoriseringskodflödet returnerar implicit beviljandeflöde inte en uppdateringstoken.

Det här autentiseringsflödet innehåller inte programscenarier som använder plattformsoberoende JavaScript-ramverk som Elektron och React-Native. Dessa scenarier kräver ytterligare funktioner för interaktion med de interna plattformarna.

Varning

Microsoft rekommenderar att du inte använder det implicita beviljandeflödet. Det rekommenderade sättet att stödja SPA:er är OAuth 2.0-auktoriseringskodflöde (med PKCE). Vissa konfigurationer av det här flödet kräver en mycket hög grad av förtroende för programmet och medför risker som inte finns i andra flöden. Du bör bara använda det här flödet när andra säkrare flöden inte är livskraftiga. Mer information finns i säkerhetsproblemen med implicit beviljandeflöde.

Webb-API:er

Du kan använda Azure AD B2C för att skydda webbtjänster, till exempel programmets RESTful-webb-API. Webb-API:er kan använda OAuth 2.0 för att skydda sina data genom att autentisera inkommande HTTP-begäranden med hjälp av token. Anroparen för ett webb-API lägger till en token i auktoriseringshuvudet för en HTTP-begäran:

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
Accept: application/json
...

Webb-API:et kan sedan använda token för att verifiera API-anroparens identitet och för att extrahera information om anroparen från anspråk som kodas i token. Läs mer om vilka typer av token och anspråk som är tillgängliga för en app i azure AD B2C-tokenreferensen.

Ett webb-API kan ta emot token från många typer av klienter, inklusive webbprogram, skrivbordsprogram och mobila program, ensidesprogram, daemoner på serversidan och andra webb-API:er. Här är ett exempel på det fullständiga flödet för ett webbprogram som anropar ett webb-API:

  1. Webbprogrammet kör en policy och användaren fullbordar upplevelsen.
  2. Azure AD B2C returnerar en (OpenID Connect) id_token och en auktoriseringskod till webbläsaren.
  3. Webbläsaren skickar id_token och auktoriseringskoden till omdirigerings-URI:n.
  4. Webbservern validerar id_token och anger en sessionscookie.
  5. Webbservern ber Azure AD B2C om en access_token genom att ge den auktoriseringskod, programklient-ID och klientautentiseringsuppgifter.
  6. access_token och refresh_token returneras till webbservern.
  7. Webb-API:t access_token anropas i en auktoriseringsheader.
  8. Webb-API:et verifierar token.
  9. Säkra data returneras till webbprogrammet.

Mer information om auktoriseringskoder, uppdateringstoken och stegen för att hämta token finns i OAuth 2.0-protokollet.

Om du vill lära dig hur du skyddar ett webb-API med hjälp av Azure AD B2C kan du läsa självstudierna för webb-API:et i avsnittet Komma igång.

Mobila och inbyggda program

Program som är installerade på enheter, till exempel mobil- och skrivbordsprogram, behöver ofta komma åt serverdelstjänster eller webb-API:er för användarnas räkning. Du kan lägga till anpassade identitetshanteringsupplevelser i dina interna program och anropa serverdelstjänster på ett säkert sätt med hjälp av Azure AD B2C och OAuth 2.0-auktoriseringskodflödet.

I det här flödet kör applikationen policyer och tar emot en authorization_code från Microsoft Entra ID efter att användaren har slutfört policyerna. Representerar authorization_code programmets behörighet att anropa serverdelstjänster för den användare som för närvarande är inloggad. Programmet kan sedan byta authorization_code i bakgrunden mot en access_token och en refresh_token. Programmet kan använda access_token för att autentisera mot ett back-end webb-API i HTTP-begäranden. Den kan också använda refresh_token för att hämta en ny access_token när en äldre upphör att gälla.

Daemons/program på serversidan

Program som innehåller långvariga processer eller som fungerar utan närvaro av en användare behöver också ett sätt att komma åt skyddade resurser, till exempel webb-API:er. Dessa program kan autentisera och hämta token med hjälp av sina identiteter (i stället för en användares delegerade identitet) och med hjälp av OAuth 2.0-klientens autentiseringsuppgifter. Klientautentiseringsflöde är inte samma som generationsflöde, och generationsflöde bör inte användas för server-till-server-autentisering.

För Azure AD B2C är OAuth 2.0-flödet för klientens autentiseringsuppgifter för närvarande i offentlig förhandsversion. Du kan dock konfigurera flöde för klientautentiseringsuppgifter med hjälp av Microsoft Entra-ID och Microsofts identitetsplattformsslutpunkt /token (https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token) för ett Microsoft Graph-program eller ditt eget program. Mer information finns i referensartikeln för Microsoft Entra-token .

Programtyper som inte stöds

Webb-API-kedjor (för flödets räkning)

Många arkitekturer innehåller ett webb-API som behöver anropa ett annat underordnat webb-API, där båda skyddas av Azure AD B2C. Det här scenariot är vanligt hos interna klienter som har en serverdel för webb-API:et och anropar en Microsoft-onlinetjänst, till exempel Microsoft Graph API.

Det här länkade webb-API-scenariot kan stödjas med hjälp av OAuth 2.0 JWT-ägarautentiseringsbeviljande, även kallat å-behalf-of-flödet. Flödet för räkning implementeras dock för närvarande inte i Azure AD B2C.

Nästa steg

Läs mer om de inbyggda principerna som tillhandahålls av användarflöden i Azure Active Directory B2C.