Dela via

Azure AD B2C: Autentiseringsprotokoll

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) tillhandahåller identitet som en tjänst för dina appar genom att stödja två branschstandardprotokoll: OpenID Connect och OAuth 2.0. Tjänsten är standardkompatibel, men två implementeringar av dessa protokoll kan ha subtila skillnader.

Informationen i den här guiden är användbar om du skriver din kod genom att direkt skicka och hantera HTTP-begäranden, i stället för att använda ett bibliotek med öppen källkod. Vi rekommenderar att du läser den här sidan innan du går in på detaljerna för varje specifikt protokoll. Men om du redan är bekant med Azure AD B2C kan du gå direkt till referensguiderna för protokoll.

Grunderna

Varje app som använder Azure AD B2C måste registreras i din B2C-katalog i Azure Portal. Appregistreringsprocessen samlar in och tilldelar några värden till din app:

  • Ett program-ID som unikt identifierar din app.

  • En omdirigerings-URI eller paketidentifierare som kan användas för att dirigera svar tillbaka till din app.

  • Några andra scenariospecifika värden. Mer information finns i hur du registrerar ditt program.

När du har registrerat din app kommunicerar den med Azure AD B2C genom att skicka begäranden till slutpunkten:

https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/authorize
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/token

Om du använder en anpassad domän ersätter {tenant}.b2clogin.com du med den anpassade domänen, till exempel contoso.com, i slutpunkterna.

I nästan alla OAuth- och OpenID Connect-flöden är fyra parter inblandade i utbytet:

Diagram som visar de fyra OAuth 2.0-rollerna.

  • Auktoriseringsservern är Azure AD B2C-slutpunkten. Den hanterar allt som rör användarinformation och åtkomst på ett säkert sätt. Den hanterar också förtroenderelationerna mellan parterna i ett flöde. Den ansvarar för att verifiera användarens identitet, bevilja och återkalla åtkomst till resurser och utfärda token. Det kallas även identitetsprovidern.

  • Resursägaren är vanligtvis slutanvändaren. Det är den part som äger data och den har befogenhet att tillåta tredje part att komma åt dessa data eller resurser.

  • OAuth-klienten är din app. Den identifieras av dess program-ID. Det är vanligtvis den part som slutanvändarna interagerar med. Den begär också token från auktoriseringsservern. Resursägaren måste ge klienten behörighet att komma åt resursen.

  • Resursservern är den plats där resursen eller data finns. Den litar på att auktoriseringsservern autentiserar och auktoriserar OAuth-klienten på ett säkert sätt. Den använder också ägaråtkomsttoken för att säkerställa att åtkomst till en resurs kan beviljas.

Principer och användarflöden

Azure AD B2C utökar standardprotokollen OAuth 2.0 och OpenID Connect genom att införa principer. Dessa gör att Azure AD B2C kan utföra mycket mer än enkel autentisering och auktorisering.

För att hjälpa dig att konfigurera de vanligaste identitetsuppgifterna innehåller Azure AD B2C-portalen fördefinierade, konfigurerbara principer som kallas användarflöden. Användarflöden beskriver fullständigt konsumentidentitetsupplevelser, inklusive registrering, inloggning och profilredigering. Användarflöden kan definieras i ett administrativt användargränssnitt. De kan köras med hjälp av en särskild frågeparameter i HTTP-autentiseringsbegäranden.

Principer och användarflöden är inte standardfunktioner i OAuth 2.0 och OpenID Connect, så du bör ta dig tid att förstå dem. Mer information finns i referensguiden för Azure AD B2C-användarflöde.

Tokener

Azure AD B2C-implementeringen av OAuth 2.0 och OpenID Connect använder bearer-token i stor utsträckning, inklusive bearer-token som representeras som JSON-webbtoken (JWT). En bearer-token är en enkel säkerhetstoken som ger "bearer" åtkomst till en skyddad resurs.

Bäraren är en part som kan presentera token. Azure AD B2C måste först autentisera en part innan den kan ta emot en bearer-token. Men om de nödvändiga åtgärderna inte vidtas för att skydda token vid överföring och lagring kan den fångas upp och användas av en oavsiktlig part.

Vissa säkerhetstoken har inbyggda mekanismer som förhindrar obehöriga parter från att använda dem, men bearer-token har inte den här mekanismen. De måste transporteras i en säker kanal, till exempel en HTTPS (Transport Layer Security).

Om en bearer-token överförs utanför en säker kanal kan en illvillig part använda en man-in-the-middle-attack för att hämta token och använda den för att få obehörig åtkomst till en skyddad resurs. Samma säkerhetsprinciper gäller när bearer-token lagras eller cachelagras för senare användning. Se alltid till att din app överför och lagrar ägartoken på ett säkert sätt.

Säkerhetsöverväganden för extra innehavartoken finns i RFC 6750 avsnitt 5.

Mer information om de olika typerna av token som används i Azure AD B2C finns i referensen för Azure AD B2C-token.

Protokoll

När du är redo att granska några exempelbegäranden kan du börja med någon av följande handledningar. Var och en motsvarar ett visst autentiseringsscenario. Om du behöver hjälp med att avgöra vilket flöde som är rätt för dig kan du ta en titt på de typer av appar som du kan skapa med hjälp av Azure AD B2C.