OAuth 2.0-auktoriseringskodflöde i Azure Active Directory B2C

Artikel
11/06/2023

Du kan använda beviljandet av OAuth 2.0-auktoriseringskod 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 registrerings-, inloggnings- och andra identitetshanteringsuppgifter i dina ensides-, mobil- och skrivbordsappar. Den här artikeln är språkoberoende. I artikeln beskriver vi hur du skickar och tar emot HTTP-meddelanden utan att använda bibliotek med öppen källkod. När det är möjligt rekommenderar vi att du använder de Microsoft Authentication Libraries (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 internt installerade program. Du kan använda OAuth 2.0-auktoriseringskodflödet för att på ett säkert sätt hämta åtkomsttoken och uppdatera token 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) token när åtkomsttoken upphör att gälla, vanligtvis efter en timme.

Den här artikeln fokuserar på de offentliga klienternas OAuth 2.0-auktoriseringskodflöde. En offentlig klient är ett klientprogram som inte kan vara betrott 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.

Anteckning

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 mer än enkel autentisering och auktorisering. Den 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:

Ersätt {tenant} med namnet på din Azure AD B2C-klientorganisation.
Ersätt 90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 med app-ID:t för ett program som du tidigare har registrerat i din Azure AD B2C-klientorganisation.
Ersätt {policy} med namnet på en princip som du har skapat i din klientorganisation, till exempel b2c_1_sign_in.

Omdirigerings-URI krävs för ensidesappar

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

Omdirigeringstypen spa är bakåtkompatibel med det implicita flödet. Appar som för närvarande använder det implicita flödet för att hämta token kan flyttas 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 denna GET HTTP-begäran använder du webbläsaren.

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6%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	Obligatoriskt?	Description
{tenant}	Obligatorisk	Namnet på din Azure AD B2C-klientorganisation
{policy}	Obligatorisk	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`.
client_id	Obligatorisk	Program-ID:t som tilldelats din app i Azure Portal.
response_type	Obligatorisk	Svarstypen, som måste inkluderas `code` för auktoriseringskodflödet. Du kan ta emot en ID-token om du inkluderar den i svarstypen, till exempel `code+id_token`, och i det här fallet måste omfånget innehålla `openid`.
redirect_uri	Obligatorisk	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.
omfång	Obligatorisk	En blankstegsavgränsad lista över omfång. 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 token som utfärdas ä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.
response_mode	Rekommenderas	Den metod som du använder för att skicka tillbaka den resulterande auktoriseringskoden till din app. Det kan vara `query`, `form_post`eller `fragment`.
state	Rekommenderas	Ett värde som ingår i begäran som kan vara en sträng med valfritt 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.
Snabb	Valfritt	Den typ av användarinteraktion som krävs. För närvarande är `login`det enda giltiga värdet , vilket tvingar användaren att ange sina autentiseringsuppgifter för begäran. Enkel inloggning börjar inte gälla.
code_challenge	rekommenderat/obligatoriskt	Används för att skydda auktoriseringskodsbidrag via proof key for Code Exchange (PKCE). 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:ar 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 om klienten av `plain` någon anledning inte kan stödja SHA256. Om du exkluderar `code_challenge_method`, men ändå inkluderar `code_challenge`, `code_challenge` antas vara klartext. Microsofts identitetsplattform stöder både `plain` och `S256`. Mer information finns i PKCE RFC. Detta krävs för ensidesappar som använder auktoriseringskodflödet.
login_hint	No	Kan användas för att fylla i inloggningsnamnfältet på inloggningssidan i förväg. Mer information finns i Fyll i inloggningsnamnet i förväg.
domain_hint	No	Ger ett tips för 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	No	Anpassade parametrar som kan användas med anpassade principer. Till exempel dynamisk URI för anpassat sidinnehåll eller nyckel/värde-anspråksmatchare.

Nu 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 appen med det värde som du använde för redirect_uri. Den använder metoden 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	Den auktoriseringskod som appen begärde. Appen kan använda auktoriseringskoden för att begära en åtkomsttoken för en målresurs. Auktoriseringskoder är mycket kortlivade. Vanligtvis upphör de att gälla efter cirka 10 minuter.
state	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 felkodsträ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.
error_description	Ett specifikt felmeddelande som kan hjälpa dig att identifiera rotorsaken till ett autentiseringsfel.
state	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 lösa in code för en token till den avsedda resursen /token genom att skicka en POST-begäran till 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 eget webb-API för serverdelen genom att använda appens klient-ID som det begärda omfånget (vilket resulterar i en åtkomsttoken med det 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=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong

Parameter	Obligatoriskt?	Description
{tenant}	Obligatorisk	Namnet på din Azure AD B2C-klientorganisation
{policy}	Obligatorisk	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.
client_id	Obligatorisk	Program-ID:t som tilldelats din app i Azure Portal.
client_secret	Ja, i Web Apps	Programhemligheten som genererades i Azure Portal. 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. I scenarier med intern app (offentlig klient) går det inte att lagra klienthemligheter 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.
grant_type	Obligatorisk	Typ av beviljande. För auktoriseringskodflödet måste beviljandetypen vara `authorization_code`.
omfång	Rekommenderas	En blankstegsavgränsad lista över omfång. Ett enda omfångsvärde anger att Microsoft Entra ID för båda de behörigheter som begärs. Att använda klient-ID som omfång anger att din app behöver en åtkomsttoken som kan användas mot din egen tjänst eller ditt webb-API, som representeras av samma klient-ID. Omfånget `offline_access` anger att din app behöver en uppdateringstoken för långlivad å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	Obligatorisk	Auktoriseringskoden som du hämtade från `/authorize` slutpunkten.
redirect_uri	Obligatorisk	Omdirigerings-URI:n för programmet där du fick auktoriseringskoden.
code_verifier	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 eller Postman.

Ett lyckat tokensvar ser ut så här:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}

Parameter	Beskrivning
not_before	Den tid då token anses vara giltig, i epoktid.
token_type	Tokentypvärdet. Den enda typ som Microsoft Entra ID stöder är Bearer.
access_token	Den signerade JSON-webbtoken (JWT) som du begärde.
omfång	De omfång som token är giltig för. Du kan också använda omfång för att cachelagrar token för senare användning.
expires_in	Hur lång tid token är giltig (i sekunder).
refresh_token	En OAuth 2.0-uppdateringstoken. Appen kan använda denna token för att hämta ytterligare token när den aktuella token upphör att gälla. Uppdateringstoken är långlivade. 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 felkodsträ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.
error_description	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 begäranden till serverdelens 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ärdas 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=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

Parameter	Obligatoriskt?	Description
{tenant}	Obligatorisk	Namnet på din Azure AD B2C-klientorganisation
{policy}	Obligatorisk	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.
client_id	Obligatorisk	Program-ID:t som tilldelats din app i Azure Portal.
client_secret	Ja, i Web Apps	Programhemligheten som genererades i Azure Portal. 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. I scenarier med intern app (offentlig klient) går det inte att lagra klienthemligheter 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.
grant_type	Obligatorisk	Typ av beviljande. För den här delen av auktoriseringskodflödet måste beviljandetypen vara `refresh_token`.
omfång	Rekommenderas	En blankstegsavgränsad lista över omfång. Ett enda omfångsvärde anger att Microsoft Entra ID för båda de behörigheter som begärs. Att använda klient-ID som omfång anger att din app behöver en åtkomsttoken som kan användas mot din egen tjänst eller ditt webb-API, som representeras av samma klient-ID. Omfånget `offline_access` anger att din app behöver en uppdateringstoken för långlivad åtkomst till resurser. Du kan också använda omfånget `openid` för att begära en ID-token från Azure AD B2C.
redirect_uri	Valfritt	Omdirigerings-URI:n för programmet där du fick auktoriseringskoden.
refresh_token	Obligatorisk	Den ursprungliga uppdateringstoken som du hämtade i den andra delen av flödet.