Azure AD B2C: Protokoly ověřování

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ů mohou mít drobné rozdíly.

Informace v této příručce jsou užitečné, pokud kód píšete přímým odesíláním a zpracováním požadavků HTTP místo použití knihovny open source. Doporučujeme, abyste si tuto stránku přečetli dříve, než se ponoříte do podrobností o jednotlivých protokolech. Pokud už ale znáte Azure AD B2C, můžete přejít přímo k referenčním průvodcům protokolu.

Základy

Každá aplikace, která používá Azure AD B2C, musí být zaregistrovaná ve vašem adresáři B2C v Azure Portal. Proces registrace aplikace shromáždí a přiřadí vaší 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ý je možné použít ke smě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 článku 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 v koncových bodech vlastní doménou, například contoso.com.

Téměř ve všech tocích OAuth a OpenID Connect jsou do výměny zapojeny čtyři strany:

Diagram znázorňující čtyři role OAuth 2.0

  • Autorizační server je koncový bod Azure AD B2C. Bezpečně zpracovává všechno, co souvisí s uživatelskými informacemi a přístupem. Zpracovává také vztahy důvěryhodnosti mezi stranami v toku. Zodpovídá za ověření identity uživatele, udělení a odvolání přístupu k prostředkům a za 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á moc umožnit třetím stranám přístup k datům nebo prostředku.

  • Klient OAuth je vaše aplikace. Je identifikovaný podle ID aplikace. Obvykle je to strana, se kterou koncoví uživatelé komunikují. Vyžádá si také tokeny z autorizačního serveru. Vlastník prostředku musí klientovi udělit oprávnění pro přístup k prostředku.

  • Zdroj nebo data se nachází na serveru prostředků . Autorizačnímu serveru důvěřuje zabezpečenému ověřování a autorizaci klienta OAuth. Používá také nosné přístupové tokeny, aby zajistil 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. Umožňují Azure AD B2C provádět mnohem víc než jen 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 s nastavením nejběžnějších úloh identit. Toky uživatelů plně popisují prostředí identit uživatelů, 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. Je možné je spustit pomocí speciálního parametru dotazu v požadavcích na ověřování HTTP.

Zásady a toky uživatelů nejsou standardní funkce OAuth 2.0 a OpenID Connect, takže byste měli udělat čas, abyste jim porozuměli. Další informace najdete v referenční příručce k toku uživatelů Azure AD B2C.

Tokeny

Implementace Azure AD B2C OAuth 2.0 a OpenID Connect ve velké míře využívá nosné tokeny, včetně nosných tokenů, které jsou reprezentované jako webové tokeny JSON (JWT). Nosný token je jednoduchý token zabezpečení, který uděluje nosný přístup k chráněnému prostředku.

Nositelem je jakákoli strana, která může token prezentovat. Azure AD B2C musí nejprve ověřit stranu, aby získala nosný token. Pokud ale nejsou podniknuty požadované kroky k zabezpečení tokenu v přenosu a úložišti, může ho zachytit a použít nezamýšlená strana.

Některé tokeny zabezpečení mají integrované mechanismy, které brání jejich použití neoprávněným stranám, ale nosné tokeny tento mechanismus nemají. Musí se přenášet v zabezpečeném kanálu, například v protokolu HTTPS (Transport Layer Security).

Pokud se nosný token přenáší mimo zabezpečený kanál, může škodlivá strana použít útok man-in-the-middle k získání tokenu a jeho použití k získání neoprávněného přístupu k chráněnému prostředku. Stejné zásady zabezpečení platí při ukládání nosných tokenů nebo ukládání do mezipaměti pro pozdější použití. Vždy se ujistěte, že vaše aplikace přenáší a ukládá nosné tokeny zabezpečeným způsobem.

Další aspekty zabezpečení nosných tokenů najdete v dokumentu RFC 6750 Oddíl 5.

Další informace o různých typech tokenů, které se používají v Azure AD B2C, najdete v referenčních informacích k tokenům Azure AD B2C.

Protokoly

Až budete připravení zkontrolovat některé ukázkové žádosti, můžete začít jedním z následujících kurzů. Každý z nich odpovídá konkrétnímu scénáři ověřování. Pokud potřebujete pomoc s určením, který tok je pro vás nejvhodnější, podívejte se na typy aplikací, které můžete vytvářet pomocí Azure AD B2C.