Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
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) poskytuje identitu jako službu pro vaše aplikace tím, že podporuje dva oborové standardní protokoly: OpenID Connect a OAuth 2.0. Služba je kompatibilní se standardy, ale jakékoli dvě implementace těchto protokolů můžou mít drobné rozdíly.
Informace v této příručce jsou užitečné, pokud kód napíšete přímo odesíláním a zpracováním požadavků HTTP, a ne použitím opensourcové knihovny. Doporučujeme, abyste si tuto stránku přečetli, než se ponoříte do podrobností o jednotlivých protokolech. Pokud už ale azure AD B2C znáte, můžete přejít přímo do referenčních příruček protokolu.
Základy
Každá aplikace, která používá Azure AD B2C, musí být zaregistrovaná v adresáři B2C na webu Azure Portal. Proces registrace aplikace shromažďuje a přiřazuje aplikaci několik hodnot:
ID aplikace, které jednoznačně identifikuje vaši aplikaci.
Identifikátor URI přesměrování nebo identifikátor balíčku , který se dá použít k přesměrování odpovědí zpět do vaší aplikace.
Několik dalších hodnot specifických pro konkrétní scénář. Další informace najdete v tématu o registraci aplikace.
Po registraci aplikace komunikuje s Azure AD B2C odesláním požadavků do koncového bodu:
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/authorize
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/token
Pokud používáte vlastní doménu, nahraďte {tenant}.b2clogin.com ji vlastní doménou, například contoso.com, v koncových bodech.
V téměř všech tocích OAuth a OpenID Connect jsou do výměny zapojeny čtyři strany:
Autorizační server je koncový bod služby Azure AD B2C. Bezpečně zpracovává vše, co souvisí s uživatelskými informacemi a přístupem. Zpracovává také důvěryhodné vztahy mezi stranami v procesu. Zodpovídá za ověření identity uživatele, udělení a odvolání přístupu k prostředkům a vydávání tokenů. Označuje se také jako zprostředkovatel identity.
Vlastníkem prostředku je obvykle koncový uživatel. Je to strana, která vlastní data, a má možnost umožnit třetím stranám přístup k datům nebo prostředku.
Klient OAuth je vaše aplikace. Identifikuje se podle ID aplikace. Obvykle se jedná o stranu, se kterou koncoví uživatelé pracují. Také požaduje tokeny z autorizačního serveru. Vlastník prostředku musí klientovi udělit oprávnění pro přístup k prostředku.
Server prostředků je místo, kde se nachází prostředek nebo data. Autorizačnímu serveru důvěřuje bezpečnému ověření a autorizaci klienta OAuth. Používá také nosné přístupové tokeny k zajištění udělení přístupu k prostředku.
Zásady a toky uživatelů
Azure AD B2C rozšiřuje standardní protokoly OAuth 2.0 a OpenID Connect zavedením zásad. Díky tomu může Azure AD B2C provádět mnohem více než jednoduché ověřování a autorizaci.
Portál Azure AD B2C obsahuje předdefinované konfigurovatelné zásady označované jako toky uživatelů, které vám pomůžou nastavit nejběžnější úlohy identit. Uživatelské toky plně popisují zážitky uživatelských identit, včetně registrace, přihlašování a úprav profilu. Toky uživatelů je možné definovat v uživatelském rozhraní pro správu. Dají se spustit pomocí speciálního parametru dotazu v požadavcích na ověřování HTTP.
Zásady a toky uživatelů nejsou standardními funkcemi OAuth 2.0 a OpenID Connect, takže byste měli chvíli trvat, než je pochopíte. Další informace najdete v referenční příručce k toku uživatele Azure AD B2C.
Tokény
Implementace OAuth 2.0 a OpenID Connect v Azure AD B2C využívá rozsáhlé používání nosných tokenů, včetně nosných tokenů, které jsou reprezentované jako webové tokeny JSON (JWT). Nosný token je jednoduchý bezpečnostní token, který uděluje "držiteli" přístup k chráněnému prostředku.
Držitel je jakákoli strana, která může token prezentovat. Azure AD B2C musí nejprve ověřit stranu, aby mohl obdržet nosný token. Pokud se ale požadované kroky neprovedou k zabezpečení tokenu v přenosu a úložišti, může ho zachytit a používat nezamýšlená strana.
Některé tokeny zabezpečení mají integrované mechanismy, které brání neoprávněným stranám v jejich používání, ale nosné tokeny nemají tento mechanismus. Musí být přenášeny v zabezpečeném kanálu, například v protokolu HTTPS (Transport Layer Security).
Pokud je nosný token přenášen mimo zabezpečený kanál, může škodlivá strana k získání tokenu použít útok man-in-the-middle a použít ho k získání neoprávněného přístupu k chráněnému prostředku. Stejné principy zabezpečení platí, když jsou nosné tokeny uložené nebo uložené v mezipaměti pro pozdější použití. Vždy se ujistěte, že vaše aplikace bezpečně přenáší a ukládá nosné tokeny.
Další důležité informace o zabezpečení nosných tokenů najdete v dokumentu RFC 6750 Oddíl 5.
Další informace o různých typech tokenů používaných v Azure AD B2C najdete v referenčních informacích k tokenům Azure AD B2C.
Protokoly
Až budete připraveni zkontrolovat některé příklady požadavků, můžete začít jedním z následujících kurzů. Každý odpovídá konkrétnímu scénáři ověřování. Pokud potřebujete pomoc s určením toku, který tok je pro vás správný, podívejte se na typy aplikací, které můžete vytvářet pomocí Azure AD B2C.