Přihlášení k webu pomocí OpenID Připojení v Azure Active Directory B2C
OpenID Připojení je ověřovací protokol založený na OAuth 2.0, který se dá použít k bezpečnému přihlašování uživatelů k webovým aplikacím. Pomocí implementace OpenID Připojení Azure Active Directory B2C (Azure AD B2C) můžete ve webových aplikacích do Microsoft Entra ID zaregistrovat, přihlásit se a další prostředí pro správu identit. V této příručce se dozvíte, jak to provést nezávisle na jazyce. Popisuje, jak odesílat a přijímat zprávy HTTP bez použití jakékoli opensourcové knihovny.
Poznámka:
Většina opensourcových knihoven ověřování získává a ověřuje tokeny JWT pro vaši aplikaci. Místo implementace vlastního kódu doporučujeme tyto možnosti prozkoumat. Další informace naleznete v tématu Přehled knihovny Microsoft Authentication Library (MSAL) a knihovny ověřování webu Microsoft Identity.
OpenID Připojení rozšiřuje autorizační protokol OAuth 2.0 pro použití jako ověřovací protokol. Tento ověřovací protokol umožňuje provádět jednotné přihlašování. Představuje koncept tokenu ID, který klientovi umožňuje ověřit identitu uživatele a získat základní informace o profilu uživatele.
OpenID Připojení také umožňuje aplikacím bezpečně získat přístupové tokeny. Přístup k prostředkům, které autorizační server zabezpečuje, můžete použít přístupové tokeny. OpenID doporučujeme Připojení, pokud vytváříte webovou aplikaci, kterou hostujete na serveru a přistupujete přes prohlížeč. Další informace o tokenech najdete v tématu Přehled tokenů v Azure Active Directory B2C.
Azure AD B2C rozšiřuje standardní protokol OpenID Připojení o více než jednoduché ověřování a autorizaci. Představuje parametr toku uživatele, který umožňuje používat OpenID Připojení k přidání uživatelských prostředí do vaší aplikace, jako je registrace, přihlášení a správa profilů.
Odesílání žádostí o ověření
Když vaše webová aplikace potřebuje ověřit uživatele a spustit tok uživatele, může uživatele nasměrovat na /authorize koncový bod. Uživatel provede akci v závislosti na toku uživatele.
V tomto požadavku klient označuje oprávnění, která musí získat od uživatele v parametru scope , a určuje tok uživatele, který se má spustit. Pokud chcete zjistit, jak žádost funguje, vložte ji do prohlížeče a spusťte ji. Nahrazení:
{tenant}s názvem vašeho tenanta.90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6s ID aplikace, kterou jste zaregistrovali ve svém tenantovi.{application-id-uri}/{scope-name}s identifikátorem URI ID aplikace a rozsahem aplikace, kterou jste zaregistrovali ve svém tenantovi.{policy}s názvem zásady, který máte ve svém tenantovi, napříkladb2c_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
| Parametr | Požadováno | Popis |
|---|---|---|
| {tenant} | Ano | Název vašeho tenanta Azure AD B2C Pokud používáte vlastní doménu, nahraďte tenant.b2clogin.com ji svojí doménou, například fabrikam.com. |
| {policy} | Ano | Tok uživatele nebo zásady, které aplikace spouští. Zadejte název toku uživatele, který vytvoříte v tenantovi Azure AD B2C. Například: b2c_1_sign_in, b2c_1_sign_upnebo b2c_1_edit_profile. |
| client_id | Ano | ID aplikace, které azure Portal přiřadil k vaší aplikaci. |
| nonce | Ano | Hodnota zahrnutá v požadavku (vygenerovaná aplikací), která je součástí výsledného tokenu ID jako deklarace identity. Aplikace pak může tuto hodnotu ověřit, aby se omezily útoky na přehrání tokenu. Hodnota je obvykle randomizovaný jedinečný řetězec, který lze použít k identifikaci původu požadavku. |
| response_type | Ano | Musí obsahovat token ID pro Připojení OpenID. Pokud vaše webová aplikace také potřebuje tokeny pro volání webového rozhraní API, můžete použít code+id_token. |
| rozsah | Ano | Seznam oborů oddělených mezerami. Obor openid označuje oprávnění k přihlášení uživatele a získání dat o uživateli ve formě tokenů ID. Obor offline_access je volitelný pro webové aplikace. Označuje, že vaše aplikace potřebuje obnovovací token pro rozšířený přístup k prostředkům. Označuje https://{tenant-name}/{app-id-uri}/{scope} oprávnění k chráněným prostředkům, jako je webové rozhraní API. Další informace najdete v tématu Žádost o přístupový token. |
| Výzva | No | Typ interakce uživatele, kterou požadujete. Jedinou platnou hodnotou v tuto chvíli je login, která vynutí, aby uživatel zadal své přihlašovací údaje na tomto požadavku. |
| redirect_uri | Ano | Parametr redirect_uri aplikace, kde server odesílá odpovědi na ověřování do vaší aplikace. Musí přesně odpovídat jednomu z redirect_uri parametrů, které jste zaregistrovali na webu Azure Portal, s tím rozdílem, že musí být kódovaný adresou URL. |
| response_mode | No | Metoda, která se používá k odeslání výsledného autorizačního kódu zpět do vaší aplikace. Může to být buď query, form_postnebo fragment. Pro zajištění nejlepšího form_post zabezpečení doporučujeme použít režim odezvy. |
| state | No | Hodnota, kterou můžete zahrnout do požadavku, který autorizační server vrátí v odpovědi tokenu. Může to být řetězec libovolného obsahu. Náhodně vygenerovaná jedinečná hodnota se obvykle používá k zabránění útokům typu útok typu negery mezi weby. Stav se také používá ke kódování informací o stavu uživatele v aplikaci před tím, než došlo k žádosti o ověření, jako je například stránka, na které byl. Pokud nechcete na webu Azure Portal registrovat více adres URL pro přesměrování, můžete pomocí parametru state odlišit odpovědi ve vaší aplikaci od služby Azure AD B2C kvůli různým požadavkům. |
| login_hint | No | Dá se použít k předběžnému vyplnění pole pro přihlašovací jméno přihlašovací stránky. Další informace najdete v tématu Předběžné naplnění přihlašovacího jména. |
| domain_hint | No | Poskytuje nápovědu pro Azure AD B2C o zprostředkovateli sociální identity, který by se měl použít pro přihlášení. Pokud je zahrnuta platná hodnota, uživatel přejde přímo na přihlašovací stránku zprostředkovatele identity. Další informace najdete v tématu Přesměrování přihlášení k poskytovateli sociálních sítí. |
| Vlastní parametry | No | Vlastní parametry, které lze použít s vlastními zásadami. Například identifikátor URI dynamického vlastního obsahu stránky nebo překladače deklarací identity klíč-hodnota. |
V tuto chvíli se uživateli zobrazí výzva k dokončení pracovního postupu. Uživatel může muset zadat svoje uživatelské jméno a heslo, přihlásit se pomocí sociální identity nebo se zaregistrovat do adresáře. V závislosti na tom, jak je definovaný tok uživatele, může existovat libovolný další počet kroků.
Jakmile uživatel dokončí tok uživatele, vrátí se odpověď do vaší aplikace v zadaném redirect_uri parametru pomocí metody, kterou zadáte v parametru response_mode . Odpověď je stejná pro každý z předchozích případů nezávisle na toku uživatele.
Úspěšná odpověď by response_mode=fragment vypadala takto:
GET https://jwt.ms/#
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=arbitrary_data_you_can_receive_in_the_response
| Parametr | Popis |
|---|---|
| id_token | Token ID, který aplikace požadovala. Token ID můžete použít k ověření identity uživatele a zahájení relace s uživatelem. |
| code | Autorizační kód, který aplikace požadovala, pokud jste použili response_type=code+id_token. Aplikace může použít autorizační kód k vyžádání přístupového tokenu pro cílový prostředek. Autorizační kódy obvykle vyprší přibližně po 10 minutách. |
| state | state Pokud je parametr součástí požadavku, měla by se v odpovědi zobrazit stejná hodnota. Aplikace by měla ověřit, že state hodnoty v požadavku a odpovědi jsou identické. |
Do parametru redirect_uri je možné odeslat také chybové odpovědi, aby je aplikace správně zvládla:
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
| Parametr | Popis |
|---|---|
| chyba | Kód, který lze použít ke klasifikaci typů chyb, ke kterým dochází. |
| error_description | Konkrétní chybová zpráva, která může pomoct identifikovat původní příčinu chyby ověřování. |
| state | state Pokud je parametr součástí požadavku, měla by se v odpovědi zobrazit stejná hodnota. Aplikace by měla ověřit, že state hodnoty v požadavku a odpovědi jsou identické. |
Ověření tokenu ID
Jen příjem tokenu ID nestačí k ověření uživatele. Ověřte podpis tokenu ID a ověřte deklarace identity v tokenu podle požadavků vaší aplikace. Azure AD B2C používá k podepisování tokenů a ověřování platnosti tokenů JSON webové tokeny (JWT) a kryptografii veřejného klíče.
Poznámka:
Většina opensourcových knihoven ověřování ověřuje tokeny JWT pro vaši aplikaci. Místo implementace vlastní logiky ověřování doporučujeme tyto možnosti prozkoumat. Další informace naleznete v tématu Přehled knihovny Microsoft Authentication Library (MSAL) a knihovny ověřování webu Microsoft Identity.
Azure AD B2C má koncový bod metadat OpenID Připojení, který aplikaci umožňuje získat informace o Azure AD B2C za běhu. Tyto informace zahrnují koncové body, obsah tokenů a podpisové klíče tokenů. V tenantovi B2C je dokument metadat JSON pro každý tok uživatele. Dokument metadat pro b2c_1_sign_in tok fabrikamb2c.onmicrosoft.com uživatele se například nachází na adrese:
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration
Jednou z vlastností tohoto konfiguračního dokumentu je jwks_uri, jehož hodnota pro stejný tok uživatele by byla:
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys
Pokud chcete zjistit, který tok uživatele se použil k podepsání tokenu ID, máte dvě možnosti. Nejprve se uživatelské jméno toku zahrne do acr deklarace identity v tokenu ID, viz deklarace identity představující tok uživatele. Druhou možností je zakódovat tok uživatele v hodnotě parametru state při vydání požadavku a pak dekódovat, aby bylo možné určit, který tok uživatele se použil. Obě metody jsou platné.
Po získání dokumentu metadat z koncového bodu metadat OpenID Připojení metadat můžete pomocí veřejných klíčů RSA 256 ověřit podpis tokenu ID. V tomto koncovém bodu může být uvedeno více klíčů, z nichž každá je identifikovaná deklarací kid identity. Hlavička tokenu ID obsahuje kid také deklaraci identity, která označuje, které z těchto klíčů se použily k podepsání tokenu ID.
Pokud chcete ověřit tokeny z Azure AD B2C, musíte vygenerovat veřejný klíč pomocí exponent(e) a modulus(n). Abyste to mohli udělat, musíte se naučit generovat veřejný klíč v programovacím jazyce podle vašeho výběru. Oficiální dokumentace ke generování veřejného klíče s protokolem RSA najdete tady: https://tools.ietf.org/html/rfc3447#section-3.1
Po ověření podpisu tokenu ID existují různé deklarace identity, které je potřeba ověřit. Například:
nonceOvěřte deklaraci identity, abyste zabránili útokům na přehrání tokenu. Jeho hodnota by měla být ta, kterou jste zadali v žádosti o přihlášení.audOvěřte deklaraci identity a ujistěte se, že se token ID vystavil pro vaši aplikaci. Její hodnota by měla být ID aplikace.iatOvěřte token ID aexpdeklarace identity a ujistěte se, že nevypršela platnost tokenu ID.
Existuje také několik dalších ověření, která byste měli provést. Ověření jsou podrobně popsána v openID Připojení Core Spec. V závislosti na vašem scénáři můžete také chtít ověřit další deklarace identity. Mezi běžná ověření patří:
- Ujistěte se, že se uživatel nebo organizace zaregistrovala k aplikaci.
- Ujistěte se, že má uživatel správnou autorizaci nebo oprávnění.
- Ujistěte se, že došlo k určité síle ověřování, například vícefaktorové ověřování Microsoft Entra.
Po ověření tokenu ID můžete zahájit relaci s uživatelem. Deklarace identity v tokenu ID můžete použít k získání informací o uživateli ve vaší aplikaci. K použití těchto informací patří zobrazení, záznamy a autorizace.
Získání tokenu
Pokud potřebujete, aby vaše webová aplikace spouštěla jenom toky uživatelů, můžete přeskočit několik dalších částí. Tyto části platí jenom pro webové aplikace, které potřebují provádět ověřená volání webového rozhraní API, které je chráněné samotnou službou Azure AD B2C.
Autorizační kód, který jste získali (pomocí) response_type=code+id_tokenmůžete uplatnit pro token do požadovaného prostředku odesláním POST požadavku do koncového /token bodu. V Azure AD B2C můžete požádat o přístupové tokeny pro jiná rozhraní API obvyklým zadáním jejich oborů v požadavku.
Můžete také požádat o přístupový token pro vlastní back-endové webové rozhraní API vaší aplikace. V tomto případě použijete ID klienta aplikace jako požadovaný obor, což vede k přístupovém tokenu s tímto ID klienta jako "cílová skupina":
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
| Parametr | Požadováno | Popis |
|---|---|---|
| {tenant} | Ano | Název tenanta Azure AD B2C |
| {policy} | Ano | Tok uživatele, který byl použit k získání autorizačního kódu. V tomto požadavku nemůžete použít jiný tok uživatele. Přidejte tento parametr do řetězce dotazu, ne do textu POST. |
| client_id | Ano | ID aplikace, které azure Portal přiřadil k vaší aplikaci. |
| tajný klíč klienta | Ano, ve službě Web Apps | Tajný klíč aplikace vygenerovaný na webu Azure Portal. Tajné kódy klienta se používají v tomto toku pro scénáře webové aplikace, kde klient může bezpečně uložit tajný klíč klienta. V případě scénářů nativní aplikace (veřejného klienta) se tajné kódy klientů nedají bezpečně uložit, a proto se v tomto toku nepoužívají. Pokud používáte tajný klíč klienta, pravidelně ho změňte. |
| code | Ano | Autorizační kód, který jste získali na začátku toku uživatele. |
| typ grantu | Ano | Typ udělení, který musí být authorization_code určený pro tok autorizačního kódu. |
| redirect_uri | No | Parametr redirect_uri aplikace, do které jste obdrželi autorizační kód. |
| rozsah | No | Seznam oborů oddělených mezerami. Obor openid označuje oprávnění k přihlášení uživatele a získání dat o uživateli ve formě parametrů id_token. Dá se použít k získání tokenů do vlastního back-endového webového rozhraní API vaší aplikace, které je reprezentované stejným ID aplikace jako klient. Obor offline_access označuje, že vaše aplikace potřebuje obnovovací token pro rozšířený přístup k prostředkům. |
Úspěšná odpověď tokenu vypadá takto:
{
"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...",
}
| Parametr | Popis |
|---|---|
| not_before | Epocha, kdy se token stane platným. |
| token_type | Hodnota typu tokenu. Bearer je jediný podporovaný typ. |
| access_token | Podepsaný token JWT, který jste požadovali. |
| rozsah | Platné obory tokenu. |
| expires_in | Doba platnosti přístupového tokenu (v sekundách). |
| expires_on | Epocha, kdy se přístupový token stane neplatným. |
| refresh_token | Obnovovací token OAuth 2.0 Aplikace může tento token použít k získání dalších tokenů po vypršení platnosti aktuálního tokenu. Obnovovací tokeny je možné použít k zachování přístupu k prostředkům po delší dobu. Obor offline_access musí být použit v žádostech o autorizaci i token, aby bylo možné přijmout obnovovací token. |
Chybové odpovědi vypadají takto:
{
"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"
}
| Parametr | Popis |
|---|---|
| chyba | Kód, který lze použít ke klasifikaci typů chyb, ke kterým dochází. |
| error_description | Zpráva, která může pomoct identifikovat původní příčinu chyby ověřování. |
Použití tokenu
Po úspěšném získání přístupového tokenu můžete token použít v požadavcích na back-endová webová rozhraní API tak, že ho zahrnete do hlavičky Authorization :
GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
Aktualizace tokenu
Přístupové tokeny a tokeny ID jsou krátkodobé. Po vypršení jejich platnosti je nutné je aktualizovat, abyste mohli dál přistupovat k prostředkům. Když aktualizujete přístupový token, Azure AD B2C vrátí nový token. Aktualizovaný přístupový token se aktualizuje nbf (ne dříve), iat (vydáno) a exp (vypršení platnosti) deklarací identity. Všechny ostatní hodnoty deklarace identity jsou podobné hodnotám v předchozím přístupovém tokenu.
Obnovte token odesláním dalšího POST požadavku do koncového /token bodu. Tentokrát zadejte refresh_token parametr místo parametru 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
| Parametr | Požadováno | Popis |
|---|---|---|
| {tenant} | Ano | Název tenanta Azure AD B2C |
| {policy} | Ano | Tok uživatele, který byl použit k získání původního obnovovacího tokenu. V tomto požadavku nemůžete použít jiný tok uživatele. Přidejte tento parametr do řetězce dotazu, ne do textu POST. |
| client_id | Ano | ID aplikace, které azure Portal přiřadil k vaší aplikaci. |
| tajný klíč klienta | Ano, ve službě Web Apps | Tajný klíč aplikace vygenerovaný na webu Azure Portal. Tajné kódy klienta se používají v tomto toku pro scénáře webové aplikace, kde klient může bezpečně uložit tajný klíč klienta. V případě scénářů nativní aplikace (veřejného klienta) se tajné kódy klientů nedají bezpečně uložit, proto se při tomto volání nepoužívají. Pokud používáte tajný klíč klienta, pravidelně ho změňte. |
| typ grantu | Ano | Typ udělení, který musí být refresh_token pro tuto část toku autorizačního kódu. |
| refresh_token | Ano | Původní obnovovací token, který byl získán v druhé části toku. Obor offline_access musí být použit v žádostech o autorizaci i token, aby bylo možné přijmout obnovovací token. |
| redirect_uri | No | Parametr redirect_uri aplikace, do které jste obdrželi autorizační kód. |
| rozsah | No | Seznam oborů oddělených mezerami. Obor openid označuje oprávnění k přihlášení uživatele a získání dat o uživateli ve formě tokenů ID. Dá se použít k odesílání tokenů do vlastního back-endového webového rozhraní API vaší aplikace, které je reprezentováno stejným ID aplikace jako klient. Obor offline_access označuje, že vaše aplikace potřebuje obnovovací token pro rozšířený přístup k prostředkům. |
Úspěšná odpověď tokenu vypadá takto:
{
"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"
}
| Parametr | Popis |
|---|---|
| not_before | Epocha, kdy se token stane platným. |
| token_type | Hodnota typu tokenu. Bearer je jediný podporovaný typ. |
| access_token | Podepsaný token JWT, který byl požadován. |
| rozsah | Platné obory tokenu. |
| expires_in | Doba platnosti přístupového tokenu (v sekundách). |
| refresh_token | Obnovovací token OAuth 2.0 Aplikace může tento token použít k získání dalších tokenů po vypršení platnosti aktuálního tokenu. Obnovovací tokeny je možné použít k zachování přístupu k prostředkům po delší dobu. |
| refresh_token_expires_in | Doba platnosti obnovovacího tokenu (v sekundách). |
Chybové odpovědi vypadají takto:
{
"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",
}
| Parametr | Popis |
|---|---|
| chyba | Kód, který lze použít ke klasifikaci typů chyb, ke kterým dochází. |
| error_description | Zpráva, která může pomoct identifikovat původní příčinu chyby ověřování. |
Odeslání žádosti o odhlášení
Pokud chcete uživatele odhlásit z aplikace, nestačí vymazat soubory cookie aplikace nebo jinak ukončit relaci s uživatelem. Přesměrujte uživatele na Azure AD B2C a odhlaste se. Pokud to neuděláte, může se stát, že uživatel bude moct aplikaci znovu provést ověření bez opětovného zadání přihlašovacích údajů. Další informace najdete v tématu Chování relace Azure AD B2C.
Pokud se chcete uživatele odhlásit, přesměrujte ho na end_session_endpoint dokument s metadaty popsanými výše v dokumentu openID uvedený v Připojení:
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Fjwt.ms%2F
| Parametr | Požadováno | Popis |
|---|---|---|
| {tenant} | Ano | Název vašeho tenanta Azure AD B2C Pokud používáte vlastní doménu, nahraďte tenant.b2clogin.com ji svojí doménou, například fabrikam.com. |
| {policy} | Ano | Tok uživatele, který zadáte v žádosti o autorizaci. Pokud se například uživatel přihlásil pomocí b2c_1_sign_in toku uživatele, zadejte b2c_1_sign_in v žádosti o odhlášení. |
| id_token_hint | No | Dříve vydaný token ID, který se má předat koncovému bodu odhlášení, jako nápovědu k aktuální ověřené relaci koncového uživatele s klientem. Tím id_token_hint zajistíte, že se jedná post_logout_redirect_uri o registrovanou adresu URL odpovědi v nastavení aplikace Azure AD B2C. Další informace najdete v tématu Zabezpečení přesměrování odhlášení. |
| client_id | Ne* | ID aplikace, které azure Portal přiřadil k vaší aplikaci. *To se vyžaduje při použití Application konfigurace jednotného přihlašování izolace a vyžadování tokenu ID v žádosti o odhlášení je nastavena na No. |
| post_logout_redirect_uri | No | Adresa URL, na kterou se má uživatel po úspěšném odhlášení přesměrovat. Pokud není zahrnutá, Azure AD B2C zobrazí uživateli obecnou zprávu. Pokud nezadáte id_token_hint, neměli byste tuto adresu URL zaregistrovat jako adresu URL odpovědi v nastavení aplikace Azure AD B2C. |
| state | No | Pokud do žádosti o autorizaci zahrnete state parametr, vrátí autorizační server stejnou hodnotu v odpovědi na post_logout_redirect_uri. Aplikace by měla ověřit, že state hodnota v požadavku a odpovědi jsou identická. |
Při žádosti o odhlášení azure AD B2C zruší platnost relace založené na souborech cookie azure AD B2C a pokusí se odhlásit od zprostředkovatelů federovaných identit. Další informace najdete v tématu Jednotné odhlášení.
Zabezpečení přesměrování odhlášení
Po odhlášení se uživatel přesměruje na identifikátor URI, který zadáte v parametru post_logout_redirect_uri , bez ohledu na adresy URL odpovědí, které zadáte pro aplikaci. Pokud je však předán platný id_token_hint token ID a je zapnutý token Vyžadovat ID v žádostech o odhlášení, Azure AD B2C před provedením přesměrování ověří, že hodnota post_logout_redirect_uri odpovídá některému z nakonfigurovaných identifikátorů URI přesměrování aplikace. Pokud pro aplikaci nebyla nakonfigurovaná žádná odpovídající adresa URL odpovědi, zobrazí se chybová zpráva a uživatel nebude přesměrován.
Pokud chcete nastavit požadovaný token ID v žádostech o odhlášení, přečtěte si téma Konfigurace chování relace v Azure Active Directory B2C.
Další kroky
- Přečtěte si další informace o relaci Azure AD B2C.