Přihlášení do jednostránkové aplikace pomocí implicitního toku OAuth 2.0 v Azure Active Directory B2C

Důležité

Od 1. května 2025 už nebude Azure AD B2C k dispozici k nákupu pro nové zákazníky. Další informace najdete v našich nejčastějších dotazech.

Mnoho moderních aplikací má front-end jednostránkové aplikace (SPA), který je napsaný primárně v JavaScriptu. Aplikace se často píše pomocí rozhraní, jako je React, Angular nebo Vue.js. Služby SPA a další javascriptové aplikace, které běží primárně v prohlížeči, mají některé další problémy s ověřováním:

• Charakteristiky zabezpečení těchto aplikací se liší od tradičních serverových webových aplikací.

• Mnoho autorizačních serverů a zprostředkovatelů identity nepodporuje požadavky na sdílení zdrojů mezi různými doménami (CORS).

• Přesměrovávání prohlížeče na celou stránku mimo aplikaci může být pro uživatele invazivní.

Výstraha

Microsoft doporučuje nepoužívat implicitní tok udělení. Doporučený způsob podpory SPA probíhá přes tok autorizačního kódu OAuth 2.0 (s PKCE). Některé konfigurace tohoto toku vyžadují velmi vysoký stupeň důvěryhodnosti v aplikaci a nesou rizika, která nejsou přítomna v jiných tocích. Tento tok byste měli použít jenom v případě, že jiné bezpečnější toky nejsou přijatelné. Další informace najdete v tématech zabezpečení s implicitními toky udělení.

Některé architektury, jako MSAL.js 1.x, podporují pouze implicitní tok udělení. V těchto případech Azure Active Directory B2C (Azure AD B2C) podporuje implicitní tok udělení autorizace OAuth 2.0. Tok je popsaný v části 4.2 specifikace OAuth 2.0. V implicitní toku aplikace přijímá tokeny přímo z autorizované koncového bodu Azure AD B2C bez jakékoli výměny mezi servery. Veškerá logika ověřování a zpracování relací se provádí zcela v klientu JavaScript s buď přesměrováním stránky, nebo pomocí vyskakovacího okna.

Azure AD B2C rozšiřuje standardní implicitní tok OAuth 2.0 na více než jednoduché ověřování a autorizaci. Azure AD B2C zavádí parametr zásad. Pomocí parametru zásad můžete pomocí OAuth 2.0 přidat zásady do aplikace, jako je registrace, přihlášení a toky uživatelů pro správu profilů. V příkladu požadavků HTTP v tomto článku používáme pro ilustraci {tenant}.onmicrosoft.com . Pokud ho máte, nahraďte {tenant}názvem vašeho tenanta . Musíte také vytvořit uživatelský tok.

K ilustraci implicitního toku přihlašování používáme následující obrázek. Každý krok je podrobně popsaný dále v článku.

Odesílání žádostí o ověření

Když vaše webová aplikace potřebuje ověřit uživatele a spustit tok uživatele, nasměruje uživatele do koncového /authorize bodu Azure AD B2C. Uživatel provede akci v závislosti na uživatelském toku.

V tomto požadavku klient označuje oprávnění, která musí získat od uživatele v parametru scope a tok uživatele ke spuštění. Pokud chcete zjistit, jak žádost funguje, zkuste ji vložit do prohlížeče a spustit ji. Nahradit:

• {tenant} jako název vašeho tenanta Azure AD B2C.

• 00001111-aaaa-2222-bbbb-3333cccc4444 s ID aplikace, kterou jste zaregistrovali ve svém tenant.

• {policy} s názvem zásady, kterou jste vytvořili ve svém prostředí, například b2c_1_sign_in.

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=id_token+token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&response_mode=fragment
&scope=openid%20offline_access
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345

Parametry v požadavku HTTP GET jsou vysvětleny v následující tabulce.

Parametr	Povinné	Popis
{nájemník}	Ano	Název tenanta Azure AD B2C
{politika}	Ano	Název toku uživatele, který chcete spustit. Zadejte název toku uživatele, který jste vytvořili v tenantovi Azure AD B2C. Například: b2c_1_sign_in, b2c_1_sign_upnebo b2c_1_edit_profile.
client_id (identifikátor klienta)	Ano	ID aplikace, které azure Portal přiřadil k vaší aplikaci.
typ odpovědi	Ano	Musí zahrnovat id_token pro přihlášení pomocí OpenID Connect. Může obsahovat také token typ odpovědi. Pokud použijete token, aplikace může okamžitě získat přístupový token z autorizovaného koncového bodu, aniž by do autorizovaného koncového bodu vystavil druhý požadavek. Pokud použijete token typ odpovědi, parametr scope musí obsahovat obor, který určuje, pro který prostředek má být token vydán.
URI přesměrování (redirect_uri)	Ne	Identifikátor URI přesměrování vaší aplikace, kde můžou aplikace odesílat a přijímat odpovědi na ověřování. Musí přesně odpovídat jednomu z URI přesměrování, které jste přidali do registrované aplikace na portálu, s tím rozdílem, že musí být zakódovaná jako URL.
mód odezvy	Ne	Určuje metodu, která se má použít k odeslání výsledného tokenu zpět do vaší aplikace. Pro implicitní toky použijte fragment.
rozsah působnosti	Ano	Seznam rozsahů oddělených mezerami. Jedna hodnota oboru oznamuje Microsoft Entra ID obě požadovaná oprávnění. 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 dlouhodobý přístup k prostředkům.
stav / stát	Ne	Hodnota zahrnutá v požadavku, která se také vrátí v odpovědi tokenu. Může to být řetězec libovolného obsahu, který chcete použít. Obvykle se používá náhodně vygenerovaná jedinečná hodnota, aby se zabránilo útokům na padělání požadavků 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í, například stránka, na které byl uživatel, nebo tok uživatele, který se spustil.
příležitostný	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 typu přehrání tokenu. Obvykle je hodnota randomizovaný, jedinečný řetězec, který lze použít k identifikaci původu požadavku.
výzva	Ne	Typ interakce uživatele, který je potřeba. V současné době je loginjedinou platnou hodnotou . Tento parametr vynutí, aby uživatel zadal své přihlašovací údaje k tomuto požadavku. Jeden Sign-On nemá žádný účinek.

Jedná se o interaktivní část procesu. Uživateli se zobrazí výzva k dokončení pracovního postupu zásady. Uživatel může muset zadat svoje uživatelské jméno a heslo, přihlásit se pomocí sociální identity, zaregistrovat si místní účet nebo jakýkoli jiný počet kroků. Akce uživatelů závisí na tom, jak je definovaný tok uživatele.

Jakmile uživatel dokončí uživatelský postup, Azure AD B2C vrátí odpověď na vaši aplikaci prostřednictvím redirect_uri. Používá metodu zadanou v parametru response_mode . Odpověď je naprosto stejná pro každý scénář akcí uživatele, nezávisle na toku uživatele, který byl proveden.

Úspěšná odpověď

Úspěšná odpověď, která používá response_mode=fragment a response_type=id_token+token vypadá takto, s zalomením řádků pro čitelnost:

GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&token_type=Bearer
&expires_in=3599
&scope="00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier

Parametr	Popis
access_token (přístupový token)	Přístupový token, který aplikace požadovala z Azure AD B2C.
typ_tokenu	Hodnota typu tokenu. Jediným typem, který Azure AD B2C podporuje, je Bearer.
vyprší za	Doba platnosti přístupového tokenu (v sekundách).
rozsah působnosti	Obory, pro které je token platný. Obory můžete použít také k ukládání tokenů do mezipaměti pro pozdější použití.
identifikační 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. Další informace o tokenech ID a jejich obsahu najdete v referenčních informacích k tokenům Azure AD B2C.
stav / stát	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 stejné.

Chybová odpověď

Do přesměrovací URI lze také poslat chybové odpovědi, aby je aplikace mohla správně zpracovat.

GET https://aadb2cplayground.azurewebsites.net/#
error=access_denied
&error_description=the+user+canceled+the+authentication
&state=arbitrary_data_you_can_receive_in_the_response

Parametr	Popis
chyba	Kód používaný ke klasifikaci typů chyb, ke kterým dochází.
popis chyby	Konkrétní chybová zpráva, která vám může pomoct identifikovat původní příčinu chyby ověřování.
stav / stát	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 stejné.

Ověření tokenu ID

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.

Mnoho opensourcových knihoven je k dispozici pro ověřování JWT v závislosti na jazyce, který chcete použít. Zvažte prozkoumání dostupných opensourcových knihoven místo implementace vlastní logiky ověřování. Informace v tomto článku vám pomůžou zjistit, jak tyto knihovny správně používat.

Azure AD B2C má koncový bod metadat OpenID Connect. Aplikace může pomocí koncového bodu načíst informace o Azure AD B2C za běhu. Tyto informace zahrnují koncové body, obsah tokenů a podpisové klíče tokenů. Ve vašem tenantu Azure AD B2C existuje dokument metadat JSON pro každý uživatelský tok. Například dokument metadat pro tok uživatele pojmenovaný b2c_1_sign_in v tenantovi fabrikamb2c.onmicrosoft.com se 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 dokumentu konfigurace je jwks_uri. 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 (a odkud se mají načíst metadata), můžete použít některou z následujících možností:

• Název uživatelského toku je součástí acr nároku v id_token. Informace o parsování deklarací identity z tokenu ID najdete v referenčních informacích k tokenu Azure AD B2C.

• Zakódujte tok uživatele v hodnotě parametru state při vydání požadavku. Potom dekódujte state parametr a určete, který uživatelský tok byl použit.

Po získání dokumentu metadat z koncového bodu metadat OpenID Connect můžete k ověření podpisu tokenu ID použít veřejné klíče RSA-256 (umístěné v tomto koncovém bodu). V tomto koncovém bodu může být v daném okamžiku uvedeno více klíčů, z nichž každý je identifikován .kid Hlavička id_token obsahuje také kid nárok. Označuje, které z těchto klíčů se použily k podepsání tokenu ID. Další informace, včetně informací o ověřování tokenů, najdete v referenčních informacích k tokenům Azure AD B2C.

Po ověření podpisu tokenu ID vyžaduje několik deklarací identity ověření. Například:

• nonce Ověř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í.

• aud Ověřte deklaraci identity a ujistěte se, že se pro vaši aplikaci vystavil token ID. Její hodnota by měla být ID aplikace.

• Ověřte iat a exp deklarace, aby bylo zajištěno, že platnost tokenu ID nevypršela.

Několik dalších ověření, která byste měli provést, jsou podrobně popsána v specifikace OpenID Connect Core. 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ří:

• Zajištění, aby se uživatel nebo organizace zaregistrovali k aplikaci.

• Zajistěte, aby uživatel získal správnou autorizaci a oprávnění.

• Zajištění, že došlo k určité síle ověřování, například pomocí vícefaktorového ověřování Microsoft Entra.

Další informace o deklarací identity v tokenu ID najdete v referenčních informacích k tokenu Azure AD B2C.

Po ověření tokenu ID můžete zahájit relaci s uživatelem. V aplikaci použijte deklarace identity v tokenu ID k získání informací o uživateli. Tyto informace lze použít pro zobrazení, záznamy, autorizaci atd.

Získání přístupových tokenů

Pokud jediné, co vaše webové aplikace potřebují, je spouštění toků uživatelů, můžete přeskočit několik dalších částí. Informace v následujících částech platí jenom pro webové aplikace, které potřebují provádět ověřená volání webového rozhraní API chráněného samotnou službou Azure AD B2C.

Teď, když jste přihlásili uživatele do SPA, můžete získat přístupové tokeny pro volání webových API, která jsou zabezpečena pomocí Microsoft Entra ID. I když jste už token obdrželi pomocí token typu odpovědi, můžete tuto metodu použít k získání tokenů pro další prostředky bez přesměrování uživatele na opětovné přihlášení.

V typickém procesu webové aplikace byste k /token koncovému bodu udělali požadavek. Koncový bod ale nepodporuje požadavky CORS, takže volání AJAX pro získání obnovovacího tokenu není možnost. Místo toho můžete použít implicitní tok ve skrytém elementu iframe HTML k získání nových tokenů pro jiná webová rozhraní API. Tady je příklad s koncem řádků pro čitelnost:

https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
&response_mode=fragment
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
&prompt=none

Parametr	Povinné?	Popis
{nájemník}	Povinné	Název tenanta Azure AD B2C
{politika}	Povinné	Tok uživatelský, který se má spustit. Zadejte název toku uživatele, který jste vytvořili v tenantovi Azure AD B2C. Například: b2c_1_sign_in, b2c_1_sign_upnebo b2c_1_edit_profile.
client_id (identifikátor klienta)	Povinné	ID aplikace přiřazené k aplikaci na webu Azure Portal.
typ odpovědi	Povinné	Musí obsahovat id_token pro přihlášení openID Connect. Může obsahovat také typ token odpovědi. Pokud použijete token zde, může vaše aplikace okamžitě získat přístupový token z autorizovaného koncového bodu, aniž by bylo potřeba posílat druhý požadavek na autorizovaný koncový bod. Pokud použijete token typ odpovědi, parametr scope musí obsahovat obor, který určuje, pro který prostředek má být token vydán.
URI přesměrování (redirect_uri)	Doporučeno	Identifikátor URI přesměrování vaší aplikace, kde můžou aplikace odesílat a přijímat odpovědi na ověřování. Musí přesně odpovídat jednomu z identifikátorů URI přesměrování, které jste zaregistrovali na portálu, s tím rozdílem, že musí být kódovaný adresou URL.
rozsah působnosti	Povinné	Seznam rozsahů oddělených mezerami. Pro získání tokenů zahrňte všechny obory, které potřebujete pro zamýšlený prostředek.
mód odezvy	Doporučeno	Určuje metodu, která se použije k odeslání výsledného tokenu zpět do vaší aplikace. Pro implicitní tok použijte fragment. Lze zadat dva další režimy, query a form_post, ale nefungují v implicitním toku.
stav / stát	Doporučeno	Hodnota zahrnutá v požadavku, která je vrácena v odpovědi na token. Může to být řetězec libovolného obsahu, který chcete použít. Obvykle se používá náhodně vygenerovaná jedinečná hodnota, aby se zabránilo útokům na padělání požadavků 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í. Například stránka nebo zobrazení, na které se uživatel nacházel.
příležitostný	Povinné	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 typu přehrání tokenu. Obvykle je hodnota randomizovaný, jedinečný řetězec, který identifikuje původ požadavku.
výzva	Povinné	Pokud chcete aktualizovat a získat tokeny ve skrytém prvku iframe, použijte prompt=none k zajištění, že se prvek iframe nezablokuje na přihlašovací stránce a vrátí se okamžitě.
nápověda k přihlášení	Povinné	Pokud chcete aktualizovat a získat tokeny ve skrytém prvku iframe, uveďte uživatelské jméno uživatele v této nápovědě, aby bylo možné rozlišovat mezi několika relacemi, které může uživatel mít v daném okamžiku. Uživatelské jméno můžete extrahovat z dřívějšího přihlášení pomocí preferred_username deklarace identity ( profile obor je nutný k přijetí preferred_username deklarace identity).
nápověda pro doménu	Povinné	Může být consumers nebo organizations. Pokud chcete aktualizovat a získat tokeny ve skrytém prvku iframe, zahrňte hodnotu domain_hint do požadavku. Extrahujte tid deklaraci z ID tokenu dřívějšího přihlášení, abyste zjistili, jakou hodnotu použít (k přijetí profile deklarace je vyžadován tid obor). Pokud je hodnota deklarace identity tid, použijte 9188040d-6c67-4c5b-b112-36a304b66dad. V opačném případě použijte domain_hint=organizations.

Nastavením parametru prompt=none se tento požadavek buď úspěšně proběhne, nebo okamžitě selže a vrátí výsledek vaší aplikaci. Úspěšná odpověď je odeslána do vaší aplikace prostřednictvím přesměrovacího identifikátoru URI metodou určenou v parametru response_mode.

Úspěšná odpověď

Úspěšná odpověď pomocí tohoto response_mode=fragment příkladu vypadá takto:

GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
&token_type=Bearer
&expires_in=3599
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read

Parametr	Popis
access_token (přístupový token)	Token, který aplikace požadovala.
typ_tokenu	Typ tokenu bude vždy Bearer.
stav / stát	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 stejné.
vyprší za	Jak dlouho je přístupový token platný (v sekundách).
rozsah působnosti	Obory, pro které je přístupový token platný.

Chybová odpověď

Chybové odpovědi se také dají odeslat na přesměrovací URI, aby je aplikace správně zpracovala. Očekávaná prompt=nonechyba vypadá jako v tomto příkladu:

GET https://aadb2cplayground.azurewebsites.net/#
error=user_authentication_required
&error_description=the+request+could+not+be+completed+silently

Parametr	Popis
chyba	Řetězec kódu chyby, který lze použít ke klasifikaci typů chyb, ke kterým dochází. Také můžete použít řetězec k reakci na chyby.
popis chyby	Konkrétní chybová zpráva, která vám může pomoct identifikovat původní příčinu chyby ověřování.

Pokud se tato chyba zobrazí v požadavku iframe, musí se uživatel interaktivně přihlásit, aby načetl nový token.

Aktualizace tokenů

Tokeny ID a přístupové tokeny vyprší po krátké době. Vaše aplikace musí být připravená pravidelně aktualizovat tyto tokeny. Implicitní toky neumožňují získat refresh token z bezpečnostních důvodů. Pokud chcete aktualizovat některý typ tokenu, použijte implicitní tok ve skrytém elementu elementu iframe HTML. Do žádosti o autorizaci zadejte prompt=none parametr. Pokud chcete získat novou hodnotu id_token, nezapomeňte použít response_type=id_token a scope=openida parametr nonce .

Odeslání žádosti o odhlášení

Pokud chcete uživatele odhlásit z aplikace, přesměrujte ho do koncového bodu odhlášení z Azure AD B2C. V aplikaci pak můžete vymazat uživatelskou relaci. Pokud uživatele nepřesměrujete, může se stát, že se budou moct znovu přihlásit do aplikace, aniž by museli znovu zadávat přihlašovací údaje, protože mají platnou relaci Sign-On s Azure AD B2C.

Uživatele můžete jednoduše přesměrovat na end_session_endpoint, který je uveden ve stejném dokumentu metadat OpenID Connect popsaném v části Ověření tokenu ID. Například:

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F

Parametr	Povinné	Popis
{nájemník}	Ano	Název vašeho tenanta Azure AD B2C
{politika}	Ano	Tok uživatele, který chcete použít k odhlášení uživatele z aplikace. Musí to být stejný tok uživatele, který aplikace použila k přihlášení uživatele.
po_odhlášení_přesměrovací_adresa_uri	Ne	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.
stav / stát	Ne	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é.

Poznámka:

Nasměrování uživatele na end_session_endpoint vymaže některé části stavu Single Sign-On uživatele v Azure AD B2C. Neodhlásí však uživatele ze sezení u jeho poskytovatele sociálních identit. Pokud uživatel během následného přihlášení vybere stejného zprostředkovatele identity, uživatel se znovu ověří bez zadání přihlašovacích údajů. Pokud se uživatel chce odhlásit z aplikace Azure AD B2C, nemusí to nutně znamenat, že se chce úplně odhlásit ze svého facebookového účtu, například. U místních účtů se ale relace uživatele ukončí správně.

Další kroky

Podívejte se na ukázku kódu: Přihlášení pomocí Azure AD B2C v javascriptovém spa.