Webbinloggning med OpenID Anslut i Azure Active Directory B2C
OpenID Anslut är ett autentiseringsprotokoll som bygger på OAuth 2.0 och som kan användas för att logga in användare på ett säkert sätt i webbprogram. Genom att använda Azure Active Directory B2C-implementeringen (Azure AD B2C) av OpenID Anslut kan du outsourca registrering, inloggning och andra identitetshanteringsupplevelser i dina webbprogram till Microsoft Entra-ID. Den här guiden visar hur du gör det på ett språkoberoende sätt. Den beskriver hur du skickar och tar emot HTTP-meddelanden utan att använda något av våra bibliotek med öppen källkod.
Kommentar
De flesta autentiseringsbibliotek med öppen källkod hämtar och validerar JWT-token för ditt program. Vi rekommenderar att du utforskar dessa alternativ i stället för att implementera din egen kod. Mer information finns i Översikt över Microsoft Authentication Library (MSAL) och Microsoft Identity Web Authentication Library.
OpenID Anslut utökar OAuth 2.0-auktoriseringsprotokollet för användning som ett autentiseringsprotokoll. Med det här autentiseringsprotokollet kan du utföra enkel inloggning. Den introducerar begreppet ID-token, vilket gör att klienten kan verifiera användarens identitet och få grundläggande profilinformation om användaren.
OpenID Anslut gör det också möjligt för program att på ett säkert sätt hämta åtkomsttoken. Du kan använda åtkomsttoken för att komma åt resurser som auktoriseringsservern skyddar. Vi rekommenderar OpenID Anslut om du skapar ett webbprogram som du är värd för på en server och nås via en webbläsare. Mer information om token finns i Översikt över token i Azure Active Directory B2C
Azure AD B2C utökar standardprotokollet OpenID Anslut för att göra mer än enkel autentisering och auktorisering. Den introducerar parametern för användarflöde, som gör att du kan använda OpenID Anslut för att lägga till användarupplevelser i ditt program, till exempel registrering, inloggning och profilhantering.
Skicka autentiseringsbegäranden
När ditt webbprogram behöver autentisera användaren och köra ett användarflöde kan det dirigera användaren till /authorize
slutpunkten. Användaren vidtar åtgärder beroende på användarflödet.
I den här begäran anger klienten de behörigheter som krävs för att hämta från användaren i parametern scope
och anger vilket användarflöde som ska köras. Om du vill få en känsla av hur begäran fungerar klistrar du in begäran i webbläsaren och kör den. Ersätta:
{tenant}
med namnet på din klientorganisation.90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
med app-ID:t för ett program som du har registrerat i din klientorganisation.{application-id-uri}/{scope-name}
med program-ID-URI:n och omfånget för ett program som du har registrerat i din klientorganisation.{policy}
med det principnamn som du har i klientorganisationen, till exempelb2c_1_sign_in
.
GET /{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
Host: {tenant}.b2clogin.com
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code+id_token
&redirect_uri=https%3A%2F%2Fjwt.ms%2F
&response_mode=fragment
&scope=openid%20offline_access%20{application-id-uri}/{scope-name}
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
Parameter | Obligatoriskt | Beskrivning |
---|---|---|
{klient} | Ja | Namnet på din Azure AD B2C-klientorganisation. Om du använder en anpassad domän ersätter tenant.b2clogin.com du med din domän, till exempel fabrikam.com . |
{policy} | Ja | Användarflödet eller principen som appen kör. Ange namnet på ett användarflöde som du skapar i din Azure AD B2C-klientorganisation. Till exempel: b2c_1_sign_in , b2c_1_sign_up eller b2c_1_edit_profile . |
client_id | Ja | Det program-ID som Azure-portalen tilldelade ditt program. |
nonce | Ja | Ett värde som ingår i begäran (genereras av programmet) som ingår i den resulterande ID-token som ett anspråk. Programmet kan sedan verifiera det här värdet för att minimera tokenreprisattacker. Värdet är vanligtvis en slumpmässig unik sträng som kan användas för att identifiera begärans ursprung. |
response_type | Ja | Måste innehålla en ID-token för OpenID-Anslut. Om ditt webbprogram också behöver token för att anropa ett webb-API kan du använda code+id_token . |
omfattning | Ja | En blankstegsavgränsad lista med 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 programmet behöver en uppdateringstoken för utökad åtkomst till resurser. 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. |
Snabb | Nej | Vilken typ av användarinteraktion du behöver. Det enda giltiga värdet just nu är login , vilket tvingar användaren att ange sina autentiseringsuppgifter för den begäran. |
redirect_uri | Ja | Parametern redirect_uri för ditt program, där servern skickar autentiseringssvar till ditt program. Den måste exakt matcha en av de redirect_uri parametrar som du registrerade i Azure-portalen, förutom att den måste vara URL-kodad. |
response_mode | Nej | Den metod som används för att skicka tillbaka den resulterande auktoriseringskoden till ditt program. Det kan vara antingen query , form_post eller fragment . Vi rekommenderar att du använder svarsläget form_post för bästa säkerhet. |
tillstånd | Nej | Ett värde som du kan inkludera i begäran som auktoriseringsservern returnerar i tokensvaret. Det kan vara en sträng med valfritt innehåll som du vill. Ett slumpmässigt genererat unikt värde används vanligtvis 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 programmet innan autentiseringsbegäran inträffade, till exempel sidan de var på. Om du inte vill registrera flera omdirigerings-URL:er i Azure-portalen kan du använda parametern state för att skilja svar i ditt program från Azure AD B2C-tjänsten på grund av olika begäranden. |
login_hint | Nej | Kan användas för att fylla i inloggningsnamnfältet på inloggningssidan. Mer information finns i Fylla i inloggningsnamnet i förväg. |
domain_hint | 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. |
Nu uppmanas användaren att slutföra arbetsflödet. Användaren kan behöva ange sitt användarnamn och lösenord, logga in med en social identitet eller registrera sig för katalogen. Det kan finnas ett annat antal steg beroende på hur användarflödet definieras.
När användaren har slutfört användarflödet returneras ett svar till ditt program med den angivna redirect_uri
parametern med hjälp av den metod som du anger i parametern response_mode
. Svaret är detsamma för vart och ett av de föregående fallen, oberoende av användarflödet.
Ett lyckat svar med skulle response_mode=fragment
se ut så här:
GET https://jwt.ms/#
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=arbitrary_data_you_can_receive_in_the_response
Parameter | Description |
---|---|
id_token | ID-token som programmet begärde. Du kan använda ID-token för att verifiera användarens identitet och starta en session med användaren. |
kod | Auktoriseringskoden som programmet begärde om du använde response_type=code+id_token . Programmet kan använda auktoriseringskoden för att begära en åtkomsttoken för en målresurs. Auktoriseringskoder upphör vanligtvis att gälla efter cirka 10 minuter. |
tillstånd | Om en state parameter ingår i begäran bör samma värde visas i svaret. Programmet bör kontrollera att state värdena i begäran och svaret är identiska. |
Felsvar kan också skickas till parametern redirect_uri
så att programmet kan hantera dem på rätt sätt:
GET https://jwt.ms/#
error=access_denied
&error_description=AADB2C90091%3a+The+user+has+cancelled+entering+self-asserted+information.%0d%0aCorrelation+ID%3a+xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx%0d%0aTimestamp%3a+xxxx-xx-xx+xx%3a23%3a27Z%0d%0a
&state=arbitrary_data_you_can_receive_in_the_response
Parameter | Description |
---|---|
fel | En kod som kan användas för att klassificera de typer av fel som inträffar. |
error_description | Ett specifikt felmeddelande som kan hjälpa dig att identifiera rotorsaken till ett autentiseringsfel. |
tillstånd | Om en state parameter ingår i begäran bör samma värde visas i svaret. Programmet bör kontrollera att state värdena i begäran och svaret är identiska. |
Verifiera ID-token
Det räcker inte att bara ta emot en ID-token för att autentisera användaren. Verifiera ID-tokens signatur och verifiera anspråken i token enligt programmets krav. Azure AD B2C använder JSON-webbtoken (JWT) och kryptering av offentliga nycklar för att signera token och verifiera att de är giltiga.
Kommentar
De flesta autentiseringsbibliotek med öppen källkod verifierar JWT-token för ditt program. Vi rekommenderar att du utforskar dessa alternativ i stället för att implementera din egen valideringslogik. Mer information finns i Översikt över Microsoft Authentication Library (MSAL) och Microsoft Identity Web Authentication Library.
Azure AD B2C har en Slutpunkt för OpenID-Anslut metadata, som gör att ett program kan hämta information om Azure AD B2C vid körning. Den här informationen omfattar slutpunkter, tokeninnehåll och tokensigneringsnycklar. Det finns ett JSON-metadatadokument för varje användarflöde i B2C-klientorganisationen. Metadatadokumentet för b2c_1_sign_in
användarflödet i fabrikamb2c.onmicrosoft.com
finns till exempel på:
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration
En av egenskaperna för det här konfigurationsdokumentet är jwks_uri
, vars värde för samma användarflöde skulle vara:
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys
För att avgöra vilket användarflöde som användes för att signera en ID-token har du två alternativ. Först inkluderas användarflödesnamnet i anspråket acr
i ID-token, se anspråk som representerar användarflöde. Det andra alternativet är att koda användarflödet i värdet för parametern state
när du utfärdar begäran och sedan avkoda den för att avgöra vilket användarflöde som användes. Endera metoden är giltig.
När du har hämtat metadatadokumentet från OpenID Anslut metadataslutpunkt kan du använda de offentliga RSA 256-nycklarna för att verifiera signaturen för ID-token. Det kan finnas flera nycklar som anges på den här slutpunkten, var och en identifierad av ett kid
anspråk. Huvudet för ID-token innehåller också ett kid
anspråk som anger vilken av dessa nycklar som användes för att signera ID-token.
För att verifiera token från Azure AD B2C måste du generera den offentliga nyckeln med exponenten(e) och modulus(n). För att göra det måste du lära dig hur du genererar den offentliga nyckeln på ett programmeringsspråk som du väljer. Den officiella dokumentationen om generering av offentliga nycklar med RSA-protokollet finns här: https://tools.ietf.org/html/rfc3447#section-3.1
När du har verifierat signaturen för ID-token finns det olika anspråk som du behöver verifiera. Till exempel:
- Verifiera anspråket
nonce
för att förhindra tokenreprisattacker. Värdet ska vara det du angav i inloggningsbegäran. - Verifiera anspråket
aud
för att säkerställa att ID-token har utfärdats för ditt program. Dess värde bör vara programmets program-ID. - Verifiera anspråken
iat
ochexp
för att kontrollera att ID-token inte har upphört att gälla.
Det finns också flera valideringar som du bör utföra. Valideringarna beskrivs i detalj i OpenID Anslut Core Spec. Du kanske också vill verifiera fler anspråk, beroende på ditt scenario. Några vanliga valideringar är:
- Kontrollera att användaren/organisationen har registrerat sig för programmet.
- Kontrollera att användaren har rätt auktorisering/behörigheter.
- Se till att en viss autentiseringsstyrka har inträffat, till exempel Microsoft Entra multifaktorautentisering.
När ID-token har verifierats kan du starta en session med användaren. Du kan använda anspråken i ID-token för att hämta information om användaren i ditt program. Användningar för den här informationen omfattar visning, poster och auktorisering.
Hämta en token
Om du behöver ditt webbprogram för att bara köra användarflöden kan du hoppa över de kommande avsnitten. De här avsnitten gäller endast för webbprogram som behöver göra autentiserade anrop till ett webb-API som skyddas av själva Azure AD B2C.
Du kan lösa in auktoriseringskoden som du har köpt (med hjälp response_type=code+id_token
av ) för en token till den önskade 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 egna webb-API för serverdelen. I det här fallet använder du 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
Host: {tenant}.b2clogin.com
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
Parameter | Obligatoriskt | Beskrivning |
---|---|---|
{klient} | Ja | Namnet på din Azure AD B2C-klientorganisation |
{policy} | Ja | 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. Lägg till den här parametern i frågesträngen, inte i POST-brödtexten. |
client_id | Ja | Det program-ID som Azure-portalen tilldelade ditt program. |
client_secret | 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 därför inte användas i det här flödet. Om du använder en klienthemlighet ändrar du den regelbundet. |
kod | Ja | Auktoriseringskoden som du hämtade i början av användarflödet. |
grant_type | Ja | Typ av beviljande, som måste vara authorization_code för auktoriseringskodflödet. |
redirect_uri | Nej | Parametern redirect_uri för programmet där du fick auktoriseringskoden. |
omfattning | Nej | En blankstegsavgränsad lista med 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 parametrar. Den kan användas för att hämta token till ditt programs egna serverdelswebb-API, som representeras av samma program-ID som klienten. Omfånget offline_access anger att programmet behöver en uppdateringstoken för utökad åtkomst till resurser. |
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",
"expires_on": "1644254945",
"refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
Parameter | Description |
---|---|
not_before | Den epoktid då token blir giltig. |
token_type | Värdet för tokentyp. Bearer är den enda typ som stöds. |
access_token | Den signerade JWT-token som du begärde. |
omfattning | Giltiga omfång för token. |
expires_in | Hur lång tid åtkomsttoken är giltig (i sekunder). |
expires_on | Den tid då åtkomsttoken blir ogiltig. |
refresh_token | En OAuth 2.0-uppdateringstoken. Programmet kan använda den här token för att hämta fler token när den aktuella token har upphört att gälla. Uppdateringstoken kan användas för att behålla åtkomsten till resurser under längre tidsperioder. Omfånget offline_access måste ha använts i både auktoriserings- och tokenbegäranden för att kunna ta emot en uppdateringstoken. |
Felsvar ser ut så här:
{
"error": "invalid_grant",
"error_description": "AADB2C90080: The provided grant has expired. Please re-authenticate and try again. Current time: xxxxxxxxxx, Grant issued time: xxxxxxxxxx, Grant expiration time: xxxxxxxxxx\r\nCorrelation ID: xxxxxxxx-xxxx-xxxX-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-16 xx:10:52Z\r\n"
}
Parameter | Description |
---|---|
fel | En kod som kan användas för att klassificera typer av fel som inträffar. |
error_description | Ett meddelande som kan hjälpa dig att identifiera rotorsaken till ett autentiseringsfel. |
Använda token
När du har hämtat en åtkomsttoken kan du använda token i begäranden till serverdelswebb-API:er genom att inkludera den i Authorization
rubriken:
GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
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 liknar dem i den tidigare åtkomsttoken.
Uppdatera en token genom att skicka en annan POST
begäran till /token
slutpunkten. Den här gången anger du parametern refresh_token
i stället för parametern code
:
POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
Parameter | Obligatoriskt | Beskrivning |
---|---|---|
{klient} | Ja | Namnet på din Azure AD B2C-klientorganisation |
{policy} | Ja | 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. Lägg till den här parametern i frågesträngen, inte i POST-brödtexten. |
client_id | Ja | Det program-ID som Azure-portalen tilldelade ditt program. |
client_secret | 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 därför inte användas i det här anropet. Om du använder en klienthemlighet ändrar du den regelbundet. |
grant_type | Ja | Typ av beviljande, som måste vara refresh_token för den här delen av auktoriseringskodflödet. |
refresh_token | Ja | Den ursprungliga uppdateringstoken som hämtades i den andra delen av flödet. Omfånget offline_access måste användas i både auktoriserings- och tokenbegäranden för att kunna ta emot en uppdateringstoken. |
redirect_uri | Nej | Parametern redirect_uri för programmet där du fick auktoriseringskoden. |
omfattning | Nej | En blankstegsavgränsad lista med 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. Den kan användas för att skicka token till ditt programs egna serverdelswebb-API, som representeras av samma program-ID som klienten. Omfånget offline_access anger att programmet behöver en uppdateringstoken för utökad åtkomst till resurser. |
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...",
"refresh_token_expires_in": "1209600"
}
Parameter | Description |
---|---|
not_before | Den epoktid då token blir giltig. |
token_type | Värdet för tokentyp. Bearer är den enda typ som stöds. |
access_token | Den signerade JWT-token som begärdes. |
omfattning | Giltiga omfång för token. |
expires_in | Hur lång tid åtkomsttoken är giltig (i sekunder). |
refresh_token | En OAuth 2.0-uppdateringstoken. Programmet kan använda den här token för att hämta ytterligare token när den aktuella token upphör att gälla. Uppdateringstoken kan användas för att behålla åtkomsten till resurser under längre tidsperioder. |
refresh_token_expires_in | Hur lång tid uppdateringstoken är giltig (i sekunder). |
Felsvar ser ut så här:
{
"error": "invalid_grant",
"error_description": "AADB2C90129: The provided grant has been revoked. Please reauthenticate and try again.\r\nCorrelation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-xx xx:xx:xxZ\r\n",
}
Parameter | Description |
---|---|
fel | En kod som kan användas för att klassificera typer av fel som inträffar. |
error_description | Ett meddelande som kan hjälpa dig att identifiera rotorsaken till ett autentiseringsfel. |
Skicka en utloggningsbegäran
När du vill logga ut användaren från programmet räcker det inte att rensa programmets cookies eller på annat sätt avsluta sessionen med användaren. Omdirigera användaren till Azure AD B2C för att logga ut. Om du inte gör det kanske användaren kan autentisera till ditt program igen utan att ange sina autentiseringsuppgifter igen. Mer information finns i Beteende för Azure AD B2C-sessioner.
Om du vill logga ut användaren omdirigerar du användaren till end_session_endpoint
det som visas i dokumentet OpenID Anslut metadata som beskrevs tidigare:
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Fjwt.ms%2F
Parameter | Obligatoriskt | Beskrivning |
---|---|---|
{klient} | Ja | Namnet på din Azure AD B2C-klientorganisation. Om du använder en anpassad domän ersätter tenant.b2clogin.com du med din domän, till exempel fabrikam.com . |
{policy} | Ja | Det användarflöde som du anger i auktoriseringsbegäran. Om användaren till exempel har loggat in med b2c_1_sign_in användarflödet anger du b2c_1_sign_in i utloggningsbegäran. |
id_token_hint | Nej | En tidigare utfärdad ID-token för att skicka till utloggningsslutpunkten som ett tips om slutanvändarens aktuella autentiserade session med klienten. Säkerställer id_token_hint att post_logout_redirect_uri är en registrerad svars-URL i dina Azure AD B2C-programinställningar. Mer information finns i Skydda omdirigeringen av utloggning. |
client_id | Nej* | Det program-ID som Azure-portalen tilldelade ditt program. *Detta krävs när du använder Application SSO-konfiguration för isolering och Kräv ID-token i utloggningsbegäran är inställt på No . |
post_logout_redirect_uri | Nej | Url:en som användaren ska omdirigeras till efter lyckad utloggning. Om den inte ingår visar Azure AD B2C användaren ett allmänt meddelande. Om du inte anger en id_token_hint bör du inte registrera den här URL:en som svars-URL i dina Azure AD B2C-programinställningar. |
tillstånd | Nej | Om du inkluderar en state parameter i auktoriseringsbegäran returnerar auktoriseringsservern samma värde i svaret på post_logout_redirect_uri . Programmet bör kontrollera att state värdet i begäran och svaret är identiskt. |
Vid en utloggningsbegäran ogiltigförklarar Azure AD B2C den cookiebaserade sessionen i Azure AD B2C och försöker logga ut från federerade identitetsprovidrar. Mer information finns i Enkel inloggning.
Skydda omdirigeringen av utloggning
Efter utloggningen omdirigeras användaren till den URI som du anger i parametern post_logout_redirect_uri
, oavsett vilka svars-URL:er som du anger för programmet. Men om ett giltigt id_token_hint
skickas och Kräv ID-token i utloggningsbegäranden är aktiverat verifierar Azure AD B2C att värdet post_logout_redirect_uri
för matchar en av programmets konfigurerade omdirigerings-URI:er innan omdirigeringen utförs. Om ingen matchande svars-URL har konfigurerats för programmet visas ett felmeddelande och användaren omdirigeras inte.
Information om hur du anger den nödvändiga ID-token i utloggningsbegäranden finns i Konfigurera sessionsbeteende i Azure Active Directory B2C.
Nästa steg
- Läs mer om Azure AD B2C-session.