Přihlášení jednostránkové aplikace pomocí implicitního toku OAuth 2.0 v Azure Active Directory B2C
Mnoho moderních aplikací má front-end jednostránkové aplikace (SPA), který je napsaný primárně v JavaScriptu. Aplikace se často píše pomocí architektury, jako je React, Angular nebo Vue.js. U služeb SPA a dalších aplikací JavaScriptu, které běží primárně v prohlížeči, se s ověřováním potýkají ještě několik dalších problé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ů identit nepodporuje žádosti o sdílení prostředků mezi zdroji (CORS).
Přesměrování celostránkového prohlížeče mimo aplikaci může být pro uživatele invazní.
Doporučeným způsobem podpory spa je tok autorizačního kódu OAuth 2.0 (s PKCE).
Některé architektury, například 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 koncového bodu autorizace Azure AD B2C bez jakékoli výměny mezi servery. Veškerá logika ověřování a zpracování relací se provádí výhradně v javascriptovém klientovi pomocí přesměrování stránky nebo automaticky otevíraných oken.
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ásady. Pomocí parametru zásad můžete pomocí OAuth 2.0 přidat do aplikace zásady, jako je registrace, přihlášení a správa 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 . Také musíte mít vytvořený tok uživatele.
Následující obrázek znázorňuje implicitní tok přihlášení. Každý krok je podrobně popsán dále v článku.
Odesílání žádostí o ověření
Když webová aplikace potřebuje ověřit uživatele a spustit tok uživatele, nasměruje ho na koncový bod Azure AD B2C/authorize. Uživatel provede akci v závislosti na toku uživatele.
V tomto požadavku klient určí oprávnění, která musí získat od uživatele v parametru scope , a tok uživatele, který se má spustit. Pokud chcete zjistit, jak požadavek funguje, zkuste ho vložit do prohlížeče a spustit ho. Nahraďte:
{tenant}s názvem tenanta Azure AD B2C.90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6s ID aplikace, kterou jste zaregistrovali ve svém tenantovi.{policy}s názvem zásady, kterou jste vytvořili ve svém tenantovi, napříkladb2c_1_sign_in.
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&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ětlené v následující tabulce.
| Parametr | Povinné | Popis |
|---|---|---|
| {tenant} | Yes | Název tenanta Azure AD B2C |
| {policy} | Yes | Název toku uživatele, který chcete spustit. Zadejte název toku uživatele, který jste vytvořili v tenantovi Azure AD B2C. Příklad: b2c_1_sign_in, b2c_1_sign_upnebo b2c_1_edit_profile. |
| client_id | Yes | ID aplikace, které Azure Portal vaší aplikaci přiřadil. |
| response_type | Yes | Musí obsahovat id_token pro přihlášení OpenID Connect. Může také obsahovat typ tokenodpovědi . Pokud použijete token, může vaše aplikace okamžitě přijmout přístupový token z autorizovaného koncového bodu, aniž by na autorizaci koncového bodu vytvořila druhou žádost. Pokud použijete token typ odpovědi, scope parametr musí obsahovat obor, který označuje, pro který prostředek se má token vydat. |
| redirect_uri | No | Identifikátor URI přesměrování vaší aplikace, kde může aplikace odesílat a přijímat odpovědi na ověřování. Musí přesně odpovídat jednomu z identifikátorů URI pro 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á adresa URL. |
| response_mode | No | Určuje metodu, která se má použít k odeslání výsledného tokenu zpět do aplikace. Pro implicitní toky použijte fragment. |
| scope | Yes | Seznam oborů oddělených mezerami Jedna hodnota oboru označuje, že Microsoft Entra ID obou požadovaných 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 pro webové aplikace volitelný. Znamená to, že vaše aplikace potřebuje obnovovací token pro dlouhodobý přístup k prostředkům. |
| state | No | Hodnota zahrnutá v požadavku, která je také vrácena 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 používá také ke kódování informací o stavu uživatele v aplikaci před provedením žádosti o ověření, například stránky, na které byl uživatel, nebo o spuštěném toku uživatele. |
| Nonce | Yes | Hodnota zahrnutá v požadavku (vygenerovaná aplikací), která je zahrnutá ve výsledném tokenu ID jako deklarace identity. Aplikace pak může tuto hodnotu ověřit, aby zmírnila útoky na přehrání tokenů. Obvykle je hodnota náhodný jedinečný řetězec, který lze použít k identifikaci původu požadavku. |
| Výzva | No | Typ požadované interakce uživatele. V současné době je loginjedinou platnou hodnotou . Tento parametr vynutí, aby uživatel zadal své přihlašovací údaje k danému požadavku. Jedno Sign-On se neprojeví. |
Toto je interaktivní část toku. Uživateli se zobrazí výzva k dokončení pracovního postupu zásad. Uživatel může muset zadat své 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živatele závisí na tom, jak je tok uživatele definován.
Jakmile uživatel dokončí tok uživatele, vrátí Azure AD B2C odpověď vaší aplikaci prostřednictvím redirect_uri. Používá metodu zadanou v parametru response_mode . Odpověď je pro každý scénář akcí uživatele naprosto stejná, nezávisle na spuštěné toku uživatele.
Úspěšná odpověď
Úspěšná odpověď, která používá response_mode=fragment a response_type=id_token+token vypadá takto, se zalomením řádků pro čitelnost:
GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&token_type=Bearer
&expires_in=3599
&scope="90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
| Parametr | Popis |
|---|---|
| access_token | Přístupový token, který aplikace požadovala od Azure AD B2C. |
| token_type | Hodnota typu tokenu. Jediný typ, který Azure AD B2C podporuje, je Bearer. |
| expires_in | Doba platnosti přístupového tokenu (v sekundách). |
| scope | Obory, pro které je token platný. Obory můžete také použít k ukládání tokenů do mezipaměti pro pozdější použití. |
| 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. Další informace o tokenech ID a jejich obsahu najdete v referenčních informacích k tokenům Azure AD B2C. |
| 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 jsou hodnoty v požadavku a odpovědi identické. |
Chybová odpověď
Odpovědi na chyby je také možné odeslat na identifikátor URI přesměrování, aby je aplikace správně zpracovala:
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 |
|---|---|
| error | Kód sloužící ke klasifikaci typů chyb, ke kterým dochází. |
| error_description | Konkrétní chybová zpráva, která vám 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 jsou hodnoty v požadavku a odpovědi identické. |
Ověření tokenu ID
Přijetí tokenu ID k ověření uživatele nestačí. 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ěření jejich platnosti webové tokeny JSON (JWT) a kryptografii s veřejnými klíči.
Pro ověřování uzlů JWT je k dispozici mnoho opensourcových knihoven v závislosti na preferovaný jazyk. 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 koncový bod použít k načtení informací o Azure AD B2C za běhu. Tyto informace zahrnují koncové body, obsah tokenů a podpisové klíče tokenů. Pro každý tok uživatele v tenantovi Azure AD B2C je k dispozici dokument metadat JSON. Například dokument metadat pro tok uživatele s názvem b2c_1_sign_in v tenantovi fabrikamb2c.onmicrosoft.com se nachází tady:
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 stejného toku 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 toku uživatele je součástí
acrdeklarace identity vid_token. Informace o tom, jak analyzovat deklarace identity z tokenu ID, najdete v referenčních informacích k tokenu Azure AD B2C.Zakódujte tok uživatele do hodnoty parametru
statepři vystavení požadavku. Potom dekódujte parametr astateurčete, který tok uživatele se použil.
Po získání dokumentu metadat z koncového bodu metadat OpenID Connect můžete pomocí veřejných klíčů RSA-256 (umístěných v tomto koncovém bodu) ověřit podpis tokenu ID. V každém okamžiku může být v tomto koncovém bodu uvedeno více klíčů, z nichž každý je identifikovaný pomocí kid. Hlavička obsahuje id_tokenkid také deklaraci identity. Urč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 je potřeba ověřit několik deklarací identity. Příklad:
Ověřte deklaraci identity,
nonceabyste zabránili útokům na přehrání tokenů. Jeho hodnota by měla být hodnota, 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. Jeho hodnotou by mělo být ID aplikace.iatOvěřte deklarace identity a aexpujistěte se, že nevypršela platnost tokenu ID.
Několik dalších ověření, která byste měli provést, je podrobně popsáno ve specifikaci 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ří:
Ujistěte se, že se uživatel nebo organizace zaregistrovali k aplikaci.
Zajištění, aby uživatel získal správnou autorizaci a oprávnění.
Zajištění určité síly ověřování, například pomocí Microsoft Entra vícefaktorového ověřování.
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 se dají použít k zobrazení, záznamům, autorizaci atd.
Získání přístupových tokenů
Pokud vaše webové aplikace potřebují jenom spouštět toky 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 Azure AD B2C.
Teď, když jste uživatele přihlásili do spa, můžete získat přístupové tokeny pro volání webových rozhraní API, která jsou zabezpečená Microsoft Entra ID. I když jste již obdrželi token pomocí token typu odpovědi, můžete tuto metodu použít k získání tokenů pro další prostředky, aniž byste uživatele přesměrovali, aby se znovu přihlásil.
V typickém toku webové aplikace byste udělali požadavek na /token koncový bod. Koncový bod ale nepodporuje požadavky CORS, takže volání AJAX za účelem získání obnovovacího tokenu není možné. Místo toho můžete použít implicitní tok ve skrytém elementu HTML iframe k získání nových tokenů pro jiná webová rozhraní API. Tady je příklad se zalomeními řádků pro čitelnost:
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&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é? | Description |
|---|---|---|
| {tenant} | Vyžadováno | Název vašeho tenanta Azure AD B2C |
| {policy} | Vyžadováno | Tok uživatele, který se má spustit. Zadejte název toku uživatele, který jste vytvořili v tenantovi Azure AD B2C. Příklad: b2c_1_sign_in, b2c_1_sign_upnebo b2c_1_edit_profile. |
| client_id | Vyžadováno | ID aplikace přiřazené vaší aplikaci v Azure Portal. |
| response_type | Vyžadováno | Musí obsahovat id_token přihlašovací údaje OpenID Connect. Může také obsahovat typ tokenodpovědi . Pokud použijete token tento příkaz, vaše aplikace může okamžitě přijmout přístupový token z autorizovaného koncového bodu, aniž by na tento autorizaci vyžadovala druhou žádost. Pokud použijete token typ odpovědi, scope musí parametr obsahovat obor, který určuje, pro který prostředek se má token vystavit. |
| redirect_uri | Doporučeno | Identifikátor URI přesměrování vaší aplikace, na který může aplikace odesílat a přijímat odpovědi ověřování. Musí přesně odpovídat některému z identifikátorů URI pro přesměrování, které jste zaregistrovali na portálu, s výjimkou toho, že musí být zakódovaná adresa URL. |
| scope | Vyžadováno | Seznam oborů oddělených mezerami Pro získání tokenů zahrňte všechny obory, které potřebujete pro zamýšlený prostředek. |
| response_mode | Doporučeno | Určuje metodu, která se použije k odeslání výsledného tokenu zpět do aplikace. Pro implicitní tok použijte fragment. Je možné zadat dva další režimy a query , form_postale v implicitní toku nefungují. |
| state | Doporučeno | Hodnota zahrnutá v požadavku, která je vrácena 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 nebo zobrazení, na které byl uživatel. |
| Nonce | Vyžadováno | 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 zmírnila útoky na přehrání tokenů. Obvykle je hodnota náhodný jedinečný řetězec, který identifikuje původ požadavku. |
| Výzva | Vyžadováno | Pokud chcete aktualizovat a získat tokeny ve skrytém prvku iframe, pomocí prompt=none příkazu se ujistěte, že se prvek iframe nezablokuje na přihlašovací stránce a okamžitě se vrátí. |
| login_hint | Vyžadováno | Pokud chcete aktualizovat a získat tokeny ve skrytém prvku iframe, uveďte do této nápovědy uživatelské jméno uživatele, abyste rozlišili více relací, které uživatel může 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 se vyžaduje k získání preferred_username deklarace identity). |
| domain_hint | Vyžadováno | Může být consumers nebo organizations. Pokud chcete aktualizovat a získat tokeny ve skrytém prvku iframe, zahrňte domain_hint hodnotu do požadavku. Extrahujte tid deklaraci identity z tokenu ID dřívějšího přihlášení a určete, kterou hodnotu použít ( profile obor se vyžaduje k přijetí tid deklarace identity). tid Pokud je 9188040d-6c67-4c5b-b112-36a304b66dadhodnota deklarace identity , použijte domain_hint=consumers. V opačném případě použijte domain_hint=organizations. |
Nastavením parametru prompt=none bude tento požadavek úspěšný nebo okamžitě selže a vrátí se do vaší aplikace. Úspěšná odpověď se odešle do vaší aplikace prostřednictvím identifikátoru URI přesměrování pomocí metody zadané v parametru response_mode .
Úspěšná odpověď
Úspěšná odpověď pomocí vypadá response_mode=fragment jako v tomto příkladu:
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 | Token, který aplikace požadovala. |
| token_type | Typ tokenu bude vždy Nosný. |
| 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é. |
| expires_in | Jak dlouho je přístupový token platný (v sekundách). |
| scope | Obory, pro které je přístupový token platný. |
Odpověď na chybu
Na identifikátor URI přesměrování je také možné odeslat odpovědi na chyby, aby je aplikace zvládla odpovídajícím způsobem. 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 |
|---|---|
| error | Řetězec kódu chyby, který lze použít ke klasifikaci typů chyb, ke kterým dochází. Řetězec můžete také použít k reakci na chyby. |
| error_description | Konkrétní chybová zpráva, která vám může pomoct identifikovat původní příčinu chyby ověřování. |
Pokud se v požadavku iframe zobrazí tato chyba, musí se uživatel znovu interaktivně přihlásit, aby načetl nový token.
Obnovovací tokeny
Platnost tokenů ID i přístupových tokenů vyprší po krátké době. Vaše aplikace musí být připravená tyto tokeny pravidelně aktualizovat. Implicitní toky neumožňují získat obnovovací token z bezpečnostních důvodů. Pokud chcete aktualizovat některý z typů tokenů, použijte implicitní tok ve skrytém elementu HTML iframe. V žádosti o autorizaci zahrňte prompt=none parametr . Pokud chcete získat novou hodnotu id_token, nezapomeňte použít response_type=id_token a scope=openida nonce parametr.
Odeslání žádosti o odhlášení
Pokud chcete odhlásit uživatele z aplikace, přesměrujte ho na koncový bod pro odhlášení Azure AD B2C. Potom můžete vymazat relaci uživatele v aplikaci. Pokud uživatele nepřesměrujete, může se stát, že bude moct znovu provést ověření ve vaší aplikaci, aniž by znovu zadávali svoje přihlašovací údaje, protože má platnou relaci s jedním Sign-On s Azure AD B2C.
Uživatele můžete jednoduše přesměrovat na end_session_endpoint ten, který je uvedený ve stejném dokumentu metadat OpenID Connect popsaném v tématu Ověření tokenu ID. Pří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 |
|---|---|---|
| {tenant} | Yes | Název vašeho tenanta Azure AD B2C |
| {policy} | Yes | Tok uživatele, který chcete použít k odhlášení uživatele z aplikace. Musí se jednat o stejný tok uživatele, který aplikace použila k přihlášení uživatele. |
| post_logout_redirect_uri | No | Adresa URL, na kterou by měl být uživatel přesměrován po úspěšném odhlášení. Pokud není zahrnutý, Azure AD B2C zobrazí uživateli obecnou zprávu. |
| state | No | 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
Přesměrování uživatele na end_session_endpoint Azure AD B2C vymaže některé z jednotlivých Sign-On stavu uživatele. Neodhlásí ale uživatele z relace zprostředkovatele sociální identity uživatele. Pokud uživatel vybere stejného zprostředkovatele identity během dalšího přihlášení, uživatel se znovu ověří bez zadání svých přihlašovacích údajů. Pokud se uživatel chce odhlásit z aplikace Azure AD B2C, nemusí to nutně znamenat, že se například chce úplně odhlásit ze svého facebookového účtu. 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 ve spa JavaScriptu.