Programtyper som kan användas i Active Directory B2C

  • Artikel

Azure Active Directory B2C (Azure AD B2C) stöder autentisering för olika moderna programarkitekturer. Alla baseras på standardprotokollen OAuth 2.0 och OpenID Connect. Den här artikeln beskriver de typer av program som du kan skapa, oberoende av det språk eller den plattform som du föredrar. Du får också förståelse för de övergripande scenarierna innan du börjar utveckla program.

Alla program som använder Azure AD B2C måste registreras i din Azure AD B2C-klientorganisation med hjälp av Azure Portal. 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 svar tillbaka 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 för alla program följer ett liknande övergripande mönster:

  1. Programmet dirigerar användaren till v2.0-slutpunkten för att köra en princip.
  2. Användaren uppfyller principen enligt principdefinitionen.
  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 kontrollera att åtkomst kan beviljas.
  6. Programmet uppdaterar säkerhetstoken med jämna mellanrum.

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

Webbprogram

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-implementering 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 tillhandahåller även 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": "d9674823-dffc-4e3f-a6eb-62fe4bd48a58"
    ...
}

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

I ett webbprogram utför varje körning av en princip följande övergripande steg:

  1. Användaren bläddrar till webbappen.
  2. Webbprogrammet omdirigerar användaren till Azure AD B2C som anger att principen ska köras.
  3. Användaren slutför principen.
  4. Azure AD B2C returnerar en id_token till webbläsaren.
  5. id_token publiceras till omdirigerings-URI:n.
  6. id_token verifieras och en sessionscookie anges.
  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 webbappen 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 illustreras i följande avsnitt om webb-API:er.

Ensidesprogram

Många moderna webbprogram skapas som enkelsidiga program på klientsidan ("SPA"). 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 hämta 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 den autentiserade användaren och åtkomsttoken som behövs för att anropa skyddade API:er. Dessutom returneras uppdateringstoken som ger långsiktig åtkomst till resurser för användares räkning utan att kräva interaktion med dessa användare.

Vi rekommenderar den här metoden. Med uppdateringstoken med begränsad livslängd kan ditt program anpassa sig till moderna webbläsarbegränsningar för 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.

Enkelsidig programautentisering

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.

Vi rekommenderar inte den här metoden.

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

Webb-API:er

Du kan använda Azure AD B2C för att skydda webbtjänster, till exempel programmets RESTful-webb-API. Web 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 av 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 är kodade i token. Mer information om vilka typer av token och anspråk som är tillgängliga för en app finns i referens för Azure AD B2C-token.

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

  1. Webbprogrammet kör en princip och användaren slutför användarupplevelsen.
  2. Azure AD B2C returnerar en (OpenID Connect) id_token och en auktoriseringskod till webbläsaren.
  3. Webbläsaren skickar auktoriseringskoden id_token och 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 ange den med auktoriseringskod, programklient-ID och klientautentiseringsuppgifter.
  6. access_token och refresh_token returneras till webbservern.
  7. Webb-API:et access_token anropas med i ett auktoriseringshuvud.
  8. Webb-API:et verifierar token.
  9. Säkra data returneras till webbappen.

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

Mer information om hur du skyddar ett webb-API med hjälp av Azure AD B2C finns i självstudiekurserna om webb-API:er i Komma igång-avsnittet.

Mobila och interna 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 på ett säkert sätt anropa serverdelstjänster med hjälp av Azure AD B2C och OAuth 2.0-auktoriseringskodflödet.

I det här flödet kör programmet principer och tar emot ett authorization_code från Microsoft Entra-ID när användaren har slutfört principen. authorization_code representerar 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 .refresh_token Programmet kan använda för att autentisera access_token till ett serverdelswebb-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 genom att använda flödet för OAuth 2.0-klientautentiseringsuppgifter. Klientens autentiseringsflöde är inte detsamma som å-vägnar-flöde och å-vägnar-flöde bör inte användas för server-till-server-autentisering.

För Azure AD B2C är OAuth 2.0-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 identitetsplattform-slutpunkten /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 artikeln om Microsoft Entra tokenreferens.

Programtyper som inte stöds

Webb-API-länkar (On-Behalf-Of-flöde)

Många arkitekturer har ett webb-API som måste anropa ett annat underordnat webb-API, där både skyddas av Azure AD B2C. Det här scenariot är vanligt i interna klienter som har en webb-API-serverdel och anropar en Microsoft-onlinetjänst som Microsoft Graph API.

Det här scenariot med länkade webb-API:er kan användas genom en tilldelning av OAuth 2.0 JWT-ägarautentiseringsuppgifter, även kallat On-Behalf-Of-flöde. Flödets 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.