Sdílet prostřednictvím

Typy aplikací, které lze použít ve službě 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.

Azure Active Directory B2C (Azure AD B2C) podporuje ověřování pro různé moderní architektury aplikací. Všechny jsou založené 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 jazyce nebo platformě, kterou dáváte přednost. Pomůže vám také porozumět scénářům vysoké úrovně, než začnete vytvářet aplikace.

Každá aplikace, která používá Azure AD B2C, musí být zaregistrovaná ve vašem tenantovi Azure AD B2C pomocí webu 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, která se dá použít k směrování odpovědí zpět do vaší aplikace.

Každý požadavek odeslaný do Azure AD B2C určuje tok uživatele (předdefinované zásady) nebo vlastní zásady , 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 se řídí podobným vzorem vysoké úrovně:

  1. Aplikace nasměruje uživatele na koncový bod verze 2.0, aby provedl politiku.
  2. Uživatel dokončí pravidlo podle jeho 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ů validuje token zabezpečení, aby ověřil možnost udělení přístupu.
  6. Aplikace pravidelně aktualizuje token zabezpečení.

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

Webové aplikace

Pro webové aplikace (včetně .NET, PHP, Javy, Ruby, Pythonu a Node.js) hostovaných na webovém serveru a přístupných prostřednictvím prohlížeče podporuje Azure AD B2C OpenID Connect pro všechna uživatelská prostředí. V implementaci OpenID Connect ve službě Azure AD B2C vaše webová aplikace inicializuje uživatelské prostředí tím, že vydává žádosti o ověření na ID Microsoft Entra. 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": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

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.

Každé spuštění zásady ve webové aplikaci provádí tyto základní kroky:

  1. Uživatel přejde do webové aplikace.
  2. Webová aplikace přesměruje uživatele do Azure AD B2C s uvedením zásady, která se má provést.
  3. Uživatel dokončí úlohy související se zásadami.
  4. Azure AD B2C vrátí id_token do prohlížeče.
  5. Publikuje se id_token do identifikátoru URI přesměrování.
  6. id_token je ověřeno a nastaví se relace cookie.
  7. Uživateli se vrátí zabezpečená stránka.

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

Pokud se chcete podívat na tento scénář v akci, vyzkoušejte jednu z ukázek kódu pro přihlášení k webové aplikaci v naší části Začínáme.

Kromě usnadnění jednoduchého přihlášení může webová aplikace také potřebovat přístup k back-endové webové službě. V tomto případě může webová aplikace vykonat mírně odlišný průběh OpenID Connect a získat tokeny za použití autorizačních kódů a obnovovacích tokenů. Tento scénář je znázorněn v následující části Webová rozhraní API.

Jednostrákové aplikace

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

Azure AD B2C nabízí dvě možnosti, jak povolit jednostránka aplikacím 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 tokenů ID , aby představoval ověřeného uživatele 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 doporučujeme. Používání tokenů aktualizace s omezenou životností pomáhá vaší aplikaci přizpůsobit se moderním omezením ochrany osobních údajů souborů cookie v prohlížeči, jako je Safari ITP.

K využití tohoto toku může vaše aplikace použít knihovnu ověřování, která ji podporuje, například MSAL.js 2.x.

Jednostránkové aplikace – ověřování

Implicitní tok udělení

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

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

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í.

Webová rozhraní API

Azure AD B2C můžete použít k zabezpečení webových služeb, jako je webové rozhraní RESTful API vaší aplikace. Webová rozhraní API můžou pomocí OAuth 2.0 zabezpečit svá data ověřováním příchozích požadavků HTTP pomocí tokenů. Volající webového rozhraní API připojí token v autorizační hlavičce 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 rozhraní API a extrahovat informace o volajícím z deklarací identity, které jsou kódovány v tokenu. 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.

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ánek aplikací, démonů na straně serveru a dalších webových rozhraní API. Tady je příklad kompletního toku webové aplikace, která volá webové rozhraní API:

  1. Webová aplikace uplatní pravidlo a uživatel dokončí uživatelský zážitek.
  2. Azure AD B2C vrátí do prohlížeče autorizační kód a (OpenID Connect) id_token.
  3. Prohlížeč odesílá id_token a autorizační kód na 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 access_token tím, že poskytne autorizační kód, ID klienta aplikace a přihlašovací údaje klienta.
  6. access_token a refresh_token jsou vráceny na webový server.
  7. Webové rozhraní API se volá pomocí autorizační hlavičky access_token .
  8. Webové rozhraní API token ověří.
  9. Zabezpečená data se vrátí do webové aplikace.

Další informace o autorizačních kódech, obnovovacích tokenech a postupu získání tokenů najdete v protokolu OAuth 2.0.

Informace o zabezpečení webového rozhraní API pomocí Azure AD B2C najdete v kurzech k webovému rozhraní API v části 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 po dokončení zásady obdrží authorization_code z Microsoft Entra ID. Představuje authorization_code oprávnění aplikace volat back-endové služby jménem uživatele, který je aktuálně přihlášen. Aplikace pak může vyměnit authorization_code na pozadí za access_token a refresh_token. Aplikace může použít access_token k ověření back-endového webového rozhraní API v požadavcích HTTP. Může také použít refresh_token k získání nové access_token , když vyprší platnost starší verze.

Démony / aplikace na straně serveru

Aplikace, které obsahují dlouhotrvající procesy nebo které pracují 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 můžou ověřovat a získávat tokeny pomocí jejich identit (místo 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 pro ověřování mezi servery.

V případě 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í Microsoft Entra ID 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 referenčním článku k tokenu Microsoft Entra .

Nepodporované typy aplikací

Řetězce webových rozhraní API (tok jménem uživatele)

Mnoho architektur zahrnuje webové rozhraní API, které potřebuje volat jiné podřízené webové rozhraní API, kde obě tato rozhraní jsou zabezpečená službou Azure AD B2C. Tento scénář je běžný v nativních klientech, kteří mají back-end webového rozhraní API a volá online službu Microsoftu, jako je rozhraní Microsoft Graph API.

Tento scénář zřetězeného webového rozhraní API je možné podporovat pomocí udělení přihlašovacích údajů nosného kódu JWT OAuth 2.0, označovaného také jako tok jménem uživatele. Tok jménem druhé osoby ale v Azure AD B2C v současné době není zavedený.

Další kroky

Přečtěte si další informace o předdefinovaných zásadách poskytovaných uživatelskými toky v Azure Active Directory B2C.

  • Last updated on