OAuth 2.0-auktoriseringskodflöde i Azure Active Directory B2C
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-b8bbc0b29dc6med 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 exempelb2c_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_upeller 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_posteller 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 logindet 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. |
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 JWT som du begärde. |
| omfång | De omfång som token är giltig för. Du kan också använda omfången 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 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 felkodsträ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. |
| error_description | Ett specifikt felmeddelande som kan hjälpa dig att identifiera rotorsaken till ett autentiseringsfel. |
Använd din egen Azure AD B2C-katalog
Prova dessa begäranden själv genom att utföra följande steg. Ersätt de exempelvärden som vi använde i den här artikeln med dina egna värden.
- Skapa en Azure AD B2C-katalog. Använd namnet på din katalog i begärandena.
- Skapa ett program för att hämta ett program-ID och en omdirigerings-URI. Inkludera en intern klient i din app.
- Skapa dina användarflöden för att hämta dina användarflödesnamn.