Typy aplikací, které lze použít v Active Directory B2C

Azure Active Directory B2C (Azure AD B2C) podporuje ověřování pro různé architektury moderních aplikací. Všechny jsou založeny na standardních oborových protokolech OAuth 2.0 nebo OpenID Connect. Tento článek popisuje typy aplikací, které můžete sestavit, nezávisle na preferovaných jazykech nebo platformách. Také pomáhá pochopit scénáře vysoké úrovně před tím, než začnete sestavovat aplikace.

Každá aplikace, která používá Azure AD B2C, musí být zaregistrovaná ve vašem tenantovi Azure AD B2C pomocí Azure Portal. Proces registrace aplikace shromažďuje a přiřazuje hodnoty, například:

• ID aplikace, které jednoznačně identifikuje vaši aplikaci.
• Adresa URL odpovědi, kterou lze použít ke směrování odpovědí zpět do aplikace.

Každý požadavek odeslaný do Azure AD B2C určuje tok uživatele (předdefinované zásady) nebo vlastní zásadu, která řídí chování Azure AD B2C. Oba typy zásad umožňují vytvořit vysoce přizpůsobitelnou sadu uživatelských prostředí.

Interakce každé aplikace probíhá podle podobného vzoru:

1. Aplikace nasměruje uživatele na koncový bod v2.0, aby spustil zásadu.
2. Uživatel vykoná zásadu podle její definice.
3. Aplikace obdrží token zabezpečení z koncového bodu v2.0.
4. Aplikace používá token zabezpečení pro přístup k chráněným informacím nebo chráněnému prostředku.
5. Server prostředků ověří token zabezpečení, aby ověřil, zda lze udělit přístup.
6. Aplikace token zabezpečení pravidelně aktualizuje.

Tyto kroky se můžou mírně lišit v závislosti na typu aplikace, kterou vytváříte.

Webové aplikace

U webových aplikací (včetně .NET, PHP, Javy, Ruby, Pythonu a Node.js), které jsou hostované na webovém serveru a přístupné přes prohlížeč, Azure AD B2C podporuje OpenID Connect pro všechna uživatelská prostředí. V implementaci OpenID Connect Azure AD B2C webová aplikace iniciuje uživatelské prostředí tím, že odesílá žádosti o ověření Microsoft Entra ID. Výsledkem požadavku je id_token. Tento token zabezpečení představuje identitu uživatele. Poskytuje také informace o uživateli ve formě deklarací identity:

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "d9674823-dffc-4e3f-a6eb-62fe4bd48a58"
    ...
}

Další informace o typech tokenů a deklarací identity dostupných pro aplikaci najdete v referenčních informacích k tokenům Azure AD B2C.

Ve webové aplikaci každé spuštění zásad provádí tyto základní kroky:

1. Uživatel přejde do webové aplikace.
2. Webová aplikace přesměruje uživatele na Azure AD B2C označující zásadu, která se má spustit.
3. Uživatel dokončí zásadu.
4. Azure AD B2C vrátí do prohlížeče .id_token
5. Odešle id_token se do identifikátoru URI přesměrování.
6. Ověří id_token se a nastaví se soubor cookie relace.
7. Uživateli se vrátí zabezpečená stránka.

Ověření identity id_token uživatele pomocí veřejného podpisového klíče přijatého od Microsoft Entra ID stačí k ověření identity uživatele. Tento proces také nastaví soubor cookie relace, který lze použít k identifikaci uživatele při následných požadavcích na stránku.

Pokud chcete vidět tento scénář v akci, vyzkoušejte některou z ukázek přihlašovacího kódu webové aplikace v části Začínáme.

Kromě usnadnění jednoduchého přihlášení může webová aplikace potřebovat také přístup k back-endové webové službě. V tomto případě může webová aplikace provádět mírně odlišný tok OpenID Connect a získávat tokeny pomocí autorizačních kódů a obnovovacích tokenů. Tento scénář je znázorněn v následujícím oddílu Webová rozhraní API.

Jednostránkové aplikace

Mnoho moderních webových aplikací je vytvořeno jako jednostránkové aplikace na straně klienta ("SA"). Vývojáři je píší pomocí JavaScriptu nebo architektury SPA, jako jsou Angular, Vue nebo React. Tyto aplikace běží ve webovém prohlížeči a mají jiné charakteristiky ověřování než tradiční webové aplikace na straně serveru.

Azure AD B2C nabízí dvě možnosti, jak jednostránkovým aplikacím povolit přihlašování uživatelů a získání tokenů pro přístup k back-endovým službám nebo webovým rozhraním API:

Tok autorizačního kódu (s PKCE)

Tok autorizačního kódu OAuth 2.0 (s PKCE) umožňuje aplikaci vyměnit autorizační kód za tokeny ID , které představují ověřené uživatelské a přístupové tokeny potřebné k volání chráněných rozhraní API. Kromě toho vrací obnovovací tokeny, které poskytují dlouhodobý přístup k prostředkům jménem uživatelů bez nutnosti interakce s těmito uživateli.

Tento přístup jsme doporučili. Obnovovací tokeny s omezenou životností pomáhají vaší aplikaci přizpůsobit se moderním omezením ochrany osobních údajů v souborech cookie v prohlížeči, jako je safari ITP.

Pokud chcete tento tok využít, může vaše aplikace používat knihovnu ověřování, která ho podporuje, například MSAL.js 2.x.

Tok implicitního udělení

Některé knihovny, například MSAL.js 1.x, podporují pouze implicitní tok udělení, nebo je vaše aplikace implementovaná tak, aby používala implicitní tok. V těchto případech Azure AD B2C podporuje implicitní tok OAuth 2.0. Tok implicitního udělení umožňuje aplikaci získat ID a přístupové tokeny. Na rozdíl od toku autorizačního kódu nevrací tok implicitního udělení obnovovací token.

Tento přístup nedoporučujeme .

Tento tok ověřování nezahrnuje scénáře aplikací, které používají multiplatformní rozhraní JavaScriptu, jako jsou Electron a React-Native. Tyto scénáře vyžadují další možnosti pro interakci s nativními platformami.

Webová rozhraní API

K zabezpečení webových služeb, jako je webové rozhraní RESTful API vaší aplikace, můžete použít Azure AD B2C. Webové rozhraní API může využívat OAuth 2.0 k zabezpečení dat ověřováním příchozích žádostí HTTP pomocí tokenů. Volající webového rozhraní API připojí token v hlavičce autorizace požadavku HTTP:

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
Accept: application/json
...

Webové rozhraní API pak může pomocí tokenu ověřit identitu volajícího a extrahovat informace o volajícím z deklarací identity zakódovaných v tokenu. Další informace o typech tokenů a deklaracích identity přístupných aplikaci najdete v tématu Odkaz tokenu Azure AD B2C.

Webové rozhraní API může přijímat tokeny z mnoha typů klientů, včetně webových aplikací, desktopových a mobilních aplikací, jednostránkových aplikací, procesů démon na straně serveru a dalších webových rozhraní API. Tady je příklad úplného toku pro webovou aplikaci, která volá webové rozhraní API:

1. Webová aplikace spustí zásadu a uživatel dokončí uživatelské prostředí.
2. Azure AD B2C vrátí do prohlížeče kód (OpenID Connect) id_token a autorizační kód.
3. Prohlížeč publikuje id_token autorizační kód a do identifikátoru URI přesměrování.
4. Webový server ověří id_token a nastaví soubor cookie relace.
5. Webový server požádá Azure AD B2C o objekt access_token tím, že mu poskytne autorizační kód, ID klienta aplikace a přihlašovací údaje klienta.
6. A access_tokenrefresh_token se vrátí na webový server.
7. Webové rozhraní API se volá s hlavičkou access_token v autorizační hlavičce.
8. Webové rozhraní API token ověří.
9. Zabezpečená data se vrátí do webové aplikace.

Pro další informace o kódech autorizace a obnovovacích tokenech a návod, jak získat tokeny, si přečtěte o protokolu OAuth 2.0.

Chcete-li zjistit, jak zabezpečit webové rozhraní API pomocí Azure AD B2C, podívejte se na kurzy o webovém rozhraní API v oddílu Začínáme.

Mobilní a nativní aplikace

Aplikace nainstalované na zařízeních, jako jsou mobilní a desktopové aplikace, často potřebují přístup k back-endovým službám nebo webovým rozhraním API jménem uživatelů. Do nativních aplikací můžete přidat přizpůsobená prostředí správy identit a bezpečně volat back-endové služby pomocí Azure AD B2C a toku autorizačního kódu OAuth 2.0.

V tomto toku aplikace spustí zásady a obdrží authorization_code id Microsoft Entra poté, co uživatel zásadu dokončí. Představuje authorization_code oprávnění aplikace volat back-endové služby jménem aktuálně přihlášeného uživatele. Aplikace pak může na pozadí vyměnit authorization_code objekt za access_token a refresh_token. Aplikace může použít access_token k ověření v back-endovém webovém rozhraní API v požadavcích HTTP. Může také použít refresh_token k získání nového access_token po vypršení platnosti toho starého.

Démoni / serverové aplikace

Aplikace, které obsahují dlouhotrvající procesy nebo které fungují bez přítomnosti uživatele, potřebují také způsob přístupu k zabezpečeným prostředkům, jako jsou webová rozhraní API. Tyto aplikace se můžou ověřovat a získávat tokeny pomocí svých identit (nikoli delegované identity uživatele) a toku přihlašovacích údajů klienta OAuth 2.0. Tok přihlašovacích údajů klienta není stejný jako tok on-behalf-flow a on-behalf-flow by se neměl používat k ověřování mezi servery.

Pro Azure AD B2C je tok přihlašovacích údajů klienta OAuth 2.0 aktuálně ve verzi Public Preview. Tok přihlašovacích údajů klienta ale můžete nastavit pomocí ID Microsoft Entra a koncového bodu Microsoft identity platform /token (https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token) pro aplikaci Microsoft Graph nebo vlastní aplikaci. Další informace najdete v článku s referenčními informacemi o tokenech Microsoft Entra.

Nepodporované typy aplikací

Řetězení webových rozhraní API (tok on-behalf-of)

Mnoho architektur zahrnuje webové rozhraní API, které potřebuje volat podřízené webové rozhraní API, přičemž obě jsou zabezpečené pomocí Azure AD B2C. Tento scénář je běžný u nativních klientů, kteří mají back-end webového rozhraní API a volou online službu Microsoftu, jako je například Microsoft Graph API.

Tento scénář zřetězených webových rozhraní API může být podporován pomocí udělení přihlašovacích údajů nosiče OAuth 2.0 JWT, označovaného také jako tok on-behalf-of. V Azure AD B2C ale není tok on-behalf-of aktuálně implementovaný.

Další kroky

Přečtěte si další informace o předdefinovaných zásadách, které poskytují toky uživatelů v Azure Active Directory B2C.