Azure AD B2C: Autentiseringsprotokoll
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 skicka och hantera HTTP-begäranden direkt i stället för att använda ett öppen källkod bibliotek. Vi rekommenderar att du läser den här sidan innan du fördjupar dig i informationen om varje specifikt protokoll. Men om du redan är bekant med Azure AD B2C kan du gå direkt till referensguiderna för protokoll.
Grunderna
Alla appar som använder Azure AD B2C måste registreras i B2C-katalogen i Azure Portal. Registreringsprocessen samlar in och tilldelar några värden till din app:
Ett program-ID som identifierar din app unikt.
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 registrera 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:
Auktoriseringsservern är Azure AD B2C-slutpunkt. 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 identitetsprovider.
Resursägaren är vanligtvis slutanvändaren. Det är den part som äger data och har befogenhet att tillåta tredje part att komma åt dessa data eller resurser.
OAuth-klienten är din app. Den identifieras med 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 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. Med dessa kan Azure AD B2C 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 användaridentitetsupplevelser, 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.
Token
Den Azure AD B2C-implementeringen av OAuth 2.0 och OpenID Connect använder ägartoken i stor utsträckning, inklusive ägartoken som representeras som JSON-webbtoken (JWT). En ägartoken är en enkel säkerhetstoken som ger "ägaren" åtkomst till en skyddad resurs.
Ägarkomponenten är valfri part som kan presentera token. Azure AD B2C måste först autentisera en part innan den kan ta emot en ägartoken. Men om de nödvändiga stegen inte vidtas för att skydda token i ö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 att obehöriga parter använder dem, men ägartoken har inte den här mekanismen. De måste transporteras i en säker kanal, till exempel en transportlagersäkerhet (HTTPS).
Om en ägartoken överförs utanför en säker kanal kan en obehörig 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 ägartoken lagras eller cachelagras för senare användning. Se alltid till att appen överför och lagrar ägartoken på ett säkert sätt.
Säkerhetsöverväganden för extra ägartoken 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 självstudier. Var och en motsvarar ett visst autentiseringsscenario. Om du behöver hjälp med att avgöra vilket flöde som passar dig kan du ta en titt på vilka typer av appar du kan skapa med hjälp av Azure AD B2C.