Dela via

OAuth 2.0-auktoriseringskodflöde i Azure 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.

Du kan använda OAuth 2.0-auktoriseringskoden bevilja i appar som är installerade på en enhet för att få åtkomst till skyddade resurser, till exempel webb-API:er. Genom att använda Azure Active Directory B2C-implementeringen (Azure AD B2C) av OAuth 2.0 kan du lägga till registrering, inloggning och andra identitetshanteringsuppgifter i dina appar för en sida, mobil och skrivbord. I den här artikeln beskriver vi hur du skickar och tar emot HTTP-meddelanden utan att använda bibliotek med öppen källkod. Den här artikeln är språkoberoende. När det är möjligt rekommenderar vi att du använder microsoft-autentiseringsbibliotek (MSAL) som stöds. Ta en titt på exempelapparna som använder MSAL.

OAuth 2.0-auktoriseringskodflödet beskrivs i avsnitt 4.1 i OAuth 2.0-specifikationen. Du kan använda den för autentisering och auktorisering i de flesta programtyper, inklusive webbprogram, ensidesprogram och inbyggda program. Du kan använda OAuth 2.0-auktoriseringskodflödet för att på ett säkert sätt hämta åtkomsttoken och uppdateringstoken för dina program, som kan användas för att komma åt resurser som skyddas av en auktoriseringsserver. Med uppdateringstoken kan klienten hämta nya åtkomsttoken (och uppdatera) när åtkomsttoken upphör att gälla, vanligtvis efter en timme.

Den här artikeln fokuserar på de offentliga klienterna OAuth 2.0-auktoriseringskodflöde. En offentlig klient är alla klientprogram som inte kan vara betrodda för att på ett säkert sätt upprätthålla integriteten för ett hemligt lösenord. Detta omfattar ensidesprogram, mobilappar, skrivbordsprogram och i princip alla program som inte körs på en server.

Anmärkning

Om du vill lägga till identitetshantering i en webbapp med hjälp av Azure AD B2C använder du OpenID Connect i stället för OAuth 2.0.

Azure AD B2C utökar OAuth 2.0-standardflödena till att göra mer än enkel autentisering och auktorisering. Det introducerar användarflödet. Med användarflöden kan du använda OAuth 2.0 för att lägga till användarupplevelser i ditt program, till exempel registrering, inloggning och profilhantering. Identitetsprovidrar som använder OAuth 2.0-protokollet inkluderar Amazon, Microsoft Entra ID, Facebook, GitHub, Google och LinkedIn.

Prova HTTP-begäranden i den här artikeln:

  1. Ersätt {tenant} med namnet på din Azure AD B2C-klientorganisation.
  2. Ersätt 00001111-aaaa-2222-bbbb-3333cccc4444 med app-ID:t för ett program som du tidigare har registrerat i din Azure AD B2C-klientorganisation.
  3. Ersätt {policy} med namnet på en policy som du har skapat i din hyrdator, till exempel b2c_1_sign_in.

Inställning av omdirigerings-URI krävs för appar med en sida

Auktoriseringskodflödet för ensidesprogram kräver ytterligare konfiguration. Följ anvisningarna för att skapa en enkeltsideapplikation för att korrekt markera din omdirigerings-URI som aktiverad för CORS. Om du vill uppdatera en befintlig omdirigerings-URI för att aktivera CORS kan du klicka på frågan om migrering i avsnittet "Webb" på fliken Autentisering för appregistrering. Du kan också öppna manifestredigeraren för appregistreringar och ange fältet type för din omdirigerings-URI till spa i avsnittet replyUrlsWithType .

Omdirigeringstypen spa är bakåtkompatibel med det implicita flödet. Appar som använder det implicita flödet för att hämta token kan byta till spa omdirigerings-URI-typen utan problem och fortsätta använda det implicita flödet.

1. Hämta en auktoriseringskod

Auktoriseringskodflödet börjar med att klienten dirigerar användaren till /authorize slutpunkten. Det här är den interaktiva delen av flödet, där användaren vidtar åtgärder. I den här begäran anger klienten i parametern scope de behörigheter som krävs för att hämta från användaren. Följande exempel (med radbrytningar för läsbarhet) visar hur du hämtar en auktoriseringskod. Om du testar den här GET HTTP-begäran använder du webbläsaren.

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=00001111-aaaa-2222-bbbb-3333cccc4444%20offline_access%20https://{tenant-name}/{app-id-uri}/{scope}
&state=arbitrary_data_you_can_receive_in_the_response
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
Parameter Krävs? Beskrivning
{klient} Krävs Namnet på din Azure AD B2C-klientorganisation
{policy} Krävs Användarflödet som ska köras. Ange namnet på ett användarflöde som du har skapat i din Azure AD B2C-klientorganisation. Till exempel: b2c_1_sign_in, b2c_1_sign_up, eller b2c_1_edit_profile.
klient-id Krävs Program-ID:t som tilldelats din app i Azure Portal.
svarstyp Krävs Svarstypen, som måste inkluderas code för auktoriseringskodflödet. Du kan ta emot en ID-token om du inkluderar den i svarstypen code+id_token, till exempel , och i det här fallet måste omfånget innehålla openid.
omdirigerings_uri Krävs Omdirigerings-URI:n för din app, där autentiseringssvar skickas och tas emot av din app. Den måste exakt matcha en av de omdirigerings-URI:er som du registrerade i portalen, förutom att den måste vara URL-kodad.
omfattning Krävs En blankstegsavgränsad lista med omfattningar. Omfånget openid anger en behörighet att logga in användaren och hämta data om användaren i form av ID-token. Omfånget offline_access är valfritt för webbprogram. Det anger att ditt program behöver en uppdateringstoken för utökad åtkomst till resurser. Klient-ID anger att den utfärdade token är avsedd att användas av Azure AD B2C-registrerad klient. https://{tenant-name}/{app-id-uri}/{scope} Anger en behörighet till skyddade resurser, till exempel ett webb-API. Mer information finns i Begära en åtkomsttoken.
svarsläge Rekommenderat Den metod som du använder för att skicka tillbaka den resulterande auktoriseringskoden till din app. Det kan vara query, form_posteller fragment.
stat / tillstånd Rekommenderat Ett värde som ingår i begäran som kan vara en sträng med allt innehåll som du vill använda. Vanligtvis används ett slumpmässigt genererat unikt värde för att förhindra förfalskningsattacker mellan webbplatser. Tillståndet används också för att koda information om användarens tillstånd i appen innan autentiseringsbegäran inträffade. Till exempel sidan som användaren var på eller det användarflöde som kördes.
omedelbar Valfritt Den typ av användarinteraktion som krävs. För närvarande är logindet enda giltiga värdet , vilket tvingar användaren att ange sina autentiseringsuppgifter för den begäran. Enkel inloggning kommer inte att träda i kraft.
kodutmaning rekommenderat/obligatoriskt Används för att säkra auktoriseringskodbeviljanden via PKCE-metoden för kodutbyte. Krävs om code_challenge_method ingår. Du måste lägga till logik i ditt program för att generera code_verifier och code_challenge. code_challenge är en Base64 URL-kodad SHA256-hash för code_verifier. Du lagrar code_verifier i ditt program för senare användning och skickar code_challenge tillsammans med auktoriseringsbegäran. Mer information finns i PKCE RFC. Detta rekommenderas nu för alla programtyper – interna appar, SPA:er och konfidentiella klienter som webbappar.
code_challenge_method rekommenderat/obligatoriskt Den metod som används för att koda code_verifier för parametern code_challenge . Detta bör vara S256, men specifikationen tillåter användning av plain om av någon anledning klienten inte kan stödja SHA256.

Om du exkluderar code_challenge_method, men fortfarande inkluderar code_challenge, code_challenge antas det vara klartext. Microsofts identitetsplattform stöder både plain och S256. Mer information finns i PKCE RFC. Detta krävs för ensidesappar med hjälp av auktoriseringskodflödet.
inloggningsförslag Nej Kan användas för att fylla i inloggningsnamnfältet på inloggningssidan. Mer information finns i Fylla i inloggningsnamnet i förväg.
domäninformation Nej Ger ett tips till Azure AD B2C om den sociala identitetsprovider som ska användas för inloggning. Om ett giltigt värde ingår går användaren direkt till inloggningssidan för identitetsprovidern. Mer information finns i Omdirigera inloggning till en social provider.
Anpassade parametrar Nej Anpassade parametrar som kan användas med anpassade principer. Till exempel dynamisk URI för anpassat sidinnehåll eller nyckel/värde-anspråksmatchare.

I det här läget uppmanas användaren att slutföra användarflödets arbetsflöde. Detta kan innebära att användaren anger sitt användarnamn och lösenord, loggar in med en social identitet, registrerar sig för katalogen eller något annat antal steg. Användaråtgärder beror på hur användarflödet definieras.

När användaren har slutfört användarflödet returnerar Microsoft Entra-ID ett svar till din app till det värde som du använde för redirect_uri. Den använder den metod som anges i parametern response_mode . Svaret är exakt detsamma för varje användaråtgärdsscenarier, oberoende av användarflödet som kördes.

Ett lyckat svar som använder response_mode=query ser ut så här:

GET urn:ietf:wg:oauth:2.0:oob?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...        // the authorization_code, truncated
&state=arbitrary_data_you_can_receive_in_the_response                // the value provided in the request
Parameter Beskrivning
kod Auktoriseringskoden som appen begärde. Appen kan använda auktoriseringskoden för att begära en åtkomsttoken för en målresurs. Auktoriseringskoder är kortvariga. Vanligtvis upphör de att gälla efter cirka 10 minuter.
stat / tillstånd Se den fullständiga beskrivningen i tabellen i föregående avsnitt. Om en state parameter ingår i begäran bör samma värde visas i svaret. Appen bör kontrollera att state värdena i begäran och svaret är identiska.

Felsvar kan också skickas till omdirigerings-URI:n så att appen kan hantera dem på rätt sätt:

GET urn:ietf:wg:oauth:2.0:oob?
error=access_denied
&error_description=The+user+has+cancelled+entering+self-asserted+information
&state=arbitrary_data_you_can_receive_in_the_response
Parameter Beskrivning
fel En felkodssträng som du kan använda för att klassificera de typer av fel som inträffar. Du kan också använda strängen för att reagera på fel.
felbeskrivning Ett specifikt felmeddelande som kan hjälpa dig att identifiera rotorsaken till ett autentiseringsfel.
stat / tillstånd Se den fullständiga beskrivningen i föregående tabell. Om en state parameter ingår i begäran bör samma värde visas i svaret. Appen bör kontrollera att state värdena i begäran och svaret är identiska.

2. Hämta en åtkomsttoken

Nu när du har skaffat en auktoriseringskod kan du utbyta code mot en token till den avsedda resursen genom att skicka en POST-förfrågan till /token slutpunkten. I Azure AD B2C kan du begära åtkomsttoken för andra API:er som vanligt genom att ange deras omfång i begäran.

Du kan också begära en åtkomsttoken för appens egna webb-API för serverdelen genom att använda appens klient-ID som det begärda omfånget (vilket resulterar i en åtkomsttoken med klient-ID:t som "målgrupp"):

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong
Parameter Krävs? Beskrivning
{klient} Krävs Namnet på din Azure AD B2C-klientorganisation
{policy} Krävs Användarflödet som användes för att hämta auktoriseringskoden. Du kan inte använda ett annat användarflöde i den här begäran.
klient-id Krävs Program-ID:t som tilldelats din app i Azure Portal.
klienthemlighet Ja, i Web Apps Programhemligheten som genererades i Azure-portalen. Klienthemligheter används i det här flödet för webbappsscenarier, där klienten kan lagra en klienthemlighet på ett säkert sätt. För scenarier med intern app (offentlig klient) kan klienthemligheter inte lagras på ett säkert sätt och används därför inte i det här anropet. Om du använder en klienthemlighet ändrar du den regelbundet.
tilldelningstyp Krävs Typ av beviljande. För auktoriseringskodflödet måste beviljandetypen vara authorization_code.
omfattning Rekommenderat En blankstegsavgränsad lista med omfattningar. Ett enda omfångsvärde anger för Azure AD B2C båda de behörigheter som begärs. Att använda klient-ID:t som omfång anger att din app behöver en åtkomsttoken som kan användas mot din egen tjänst eller webb-API, som representeras av samma klient-ID. Omfånget offline_access anger att din app behöver en uppdateringstoken för långvarig åtkomst till resurser. Du kan också använda omfånget openid för att begära en ID-token från Azure AD B2C.
kod Krävs Auktoriseringskoden som du hämtade från /authorize slutpunkten.
omdirigerings_uri Krävs Omdirigerings-URI:n för programmet där du tog emot auktoriseringskoden.
kodverifiering rekommenderas Samma code_verifier som används för att hämta auktoriseringskoden. Krävs om PKCE användes i begäran om beviljande av auktoriseringskod. Mer information finns i PKCE RFC.

Om du testar den här POST HTTP-begäran kan du använda valfri HTTP-klient, till exempel Microsoft PowerShell.

Ett lyckat tokensvar ser ut så här:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
Parameter Beskrivning
inte_före Den tid då token anses vara giltig, i epoktid.
typ_av_token Värdet för tokentyp. Den enda typ som Microsoft Entra ID stöder är Bearer.
åtkomsttoken Den signerade JSON-webbtoken (JWT) som du begärde.
omfattning De områden som token är giltigt för. Du kan också använda omfång för att cachelagra token för senare bruk.
går ut om Hur lång tid token är giltig (i sekunder).
uppdaterings-token En OAuth 2.0-uppfräschningskod. Appen kan använda den här token för att hämta ytterligare token när den aktuella token har upphört att gälla. Uppdateringstoken är långvariga. Du kan använda dem för att behålla åtkomsten till resurser under längre tidsperioder. Mer information finns i referensen för Azure AD B2C-token.

Felsvar ser ut så här:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}
Parameter Beskrivning
fel En felkodssträng som du kan använda för att klassificera de typer av fel som inträffar. Du kan också använda strängen för att reagera på fel.
felbeskrivning Ett specifikt felmeddelande som kan hjälpa dig att identifiera rotorsaken till ett autentiseringsfel.

3. Använd token

Nu när du har skaffat en åtkomsttoken kan du använda token i anrop till backend-webb-API:er genom att inkludera den i Authorization rubriken.

GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

4. Uppdatera token

Åtkomsttoken och ID-token är kortvariga. När de har upphört att gälla måste du uppdatera dem för att fortsätta att komma åt resurser. När du uppdaterar åtkomsttoken returnerar Azure AD B2C en ny token. Den uppdaterade åtkomsttoken har uppdaterat nbf (inte tidigare), iat (utfärdats vid) och exp (förfallodatum) anspråksvärden. Alla andra anspråksvärden är samma som den ursprungligen utfärdade åtkomsttoken.

Om du vill uppdatera token skickar du en annan POST-begäran till /token slutpunkten. Den här gången anger du refresh_token i stället för code:

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
Parameter Krävs? Beskrivning
{klient} Krävs Namnet på din Azure AD B2C-klientorganisation
{policy} Krävs Användarflödet som användes för att hämta den ursprungliga uppdateringstoken. Du kan inte använda ett annat användarflöde i den här begäran.
klient-id Krävs Program-ID:t som tilldelats din app i Azure Portal.
klienthemlighet Ja, i Web Apps Programhemligheten som genererades i Azure-portalen. Klienthemligheter används i det här flödet för webbappsscenarier, där klienten kan lagra en klienthemlighet på ett säkert sätt. För scenarier med intern app (offentlig klient) kan klienthemligheter inte lagras på ett säkert sätt och används därför inte i det här anropet. Om du använder en klienthemlighet bör du ändra den regelbundet.
tilldelningstyp Krävs Typ av beviljande. För den här delen av auktoriseringskodflödet måste beviljandetypen vara refresh_token.
omfattning Rekommenderat En blankstegsavgränsad lista med omfattningar. Ett enda omfångsvärde anger för Microsoft Entra ID båda de behörigheter som begärs. Att använda klient-ID:t som omfång anger att din app behöver en åtkomsttoken som kan användas mot din egen tjänst eller webb-API, som representeras av samma klient-ID. Omfånget offline_access anger att din app behöver en uppdateringstoken för långvarig åtkomst till resurser. Du kan också använda omfånget openid för att begära en ID-token från Azure AD B2C.
omdirigerings_uri Valfritt Omdirigerings-URI:n för programmet där du tog emot auktoriseringskoden.
uppdaterings-token Krävs Den ursprungliga uppdateringstoken som du hämtade i den andra delen av flödet.

Ett lyckat tokensvar ser ut så här:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
Parameter Beskrivning
inte_före Den tid då token anses vara giltig, i epoktid.
typ_av_token Värdet för tokentyp. Den enda typ som Microsoft Entra ID stöder är Bearer.
åtkomsttoken Den signerade JWT som du begärde.
omfattning De områden som token är giltigt för. Du kan också använda omfången för att cachelagrar token för senare användning.
går ut om Hur lång tid token är giltig (i sekunder).
uppdaterings-token En OAuth 2.0-uppfräschningskod. Appen kan använda den här token för att hämta ytterligare token när den aktuella token har upphört att gälla. Uppdateringstoken är långlivade och kan användas för att behålla åtkomsten till resurser under längre tidsperioder. Mer information finns i referensen för Azure AD B2C-token.

Felsvar ser ut så här:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}
Parameter Beskrivning
fel En felkodssträng som du kan använda för att klassificera typer av fel som inträffar. Du kan också använda strängen för att reagera på fel.
felbeskrivning Ett specifikt felmeddelande som kan hjälpa dig att identifiera rotorsaken till ett autentiseringsfel.

Använda din egen Azure AD B2C-katalog

Utför följande steg för att prova dessa begäranden själv. Ersätt de exempelvärden som vi använde i den här artikeln med dina egna värden.

  1. Skapa en Azure AD B2C-katalog. Använd namnet på din katalog i begärandena.
  2. Skapa ett program för att hämta ett program-ID och en omdirigerings-URI. Inkludera en intern klient i din app.
  3. Skapa dina användarflöden för att hämta dina användarflödesnamn.