Typy aplikací platformy Microsoft Identity Platform a toky ověřování

Platforma Microsoft Identity Platform podporuje ověřování pro různé druhy moderních aplikačních architektur. Všechny architektury jsou založené na standardních protokolech OAuth 2.0 a OpenID Connect. Pomocí knihoven ověřování pro platformu Microsoft Identity Platform aplikace ověřují identity a získávají tokeny pro přístup k chráněným rozhraním API.

Tento článek popisuje toky ověřování a scénáře aplikací, ve kterých se používají.

Kategorie aplikací

Tokeny zabezpečení je možné získat z několika typů aplikací, mezi které patří:

• Webové aplikace
• Mobilní aplikace
• Desktopové aplikace
• Webová rozhraní API

Tokeny je možné získat také aplikacemi běžícími na zařízeních, která nemají prohlížeč nebo běží na internetu věcí (IoT).

Následující části popisují kategorie aplikací.

Chráněné prostředky vs. klientské aplikace

Scénáře ověřování zahrnují dvě aktivity:

• Získání tokenů zabezpečení pro chráněné webové rozhraní API: Doporučujeme používat knihovnu MSAL (Microsoft Authentication Library) vyvinutou a podporovanou společností Microsoft.
• Ochrana webového rozhraní API nebo webové aplikace: Jedním z úkolů ochrany těchto prostředků je ověření tokenu zabezpečení. Na některých platformách Microsoft nabízí middlewarové knihovny.

S uživateli či bez uživatelů

Většina scénářů ověřování získává tokeny jménem přihlášených uživatelů.

Jsou však také aplikace běžící na pozadí. V těchto scénářích aplikace získávají tokeny jménem sebe sama bez uživatele.

Jednostránková, veřejná klientská a důvěrná klientská aplikace

Tokeny zabezpečení je možné získat několika typy aplikací. Tyto aplikace jsou obvykle rozdělené do následujících tří kategorií. Každý se používá s různými knihovnami a objekty.

• Jednostrákové aplikace: Označované také jako spA, jedná se o webové aplikace, ve kterých tokeny získává JavaScript nebo TypeScript spuštěná v prohlížeči. Mnoho moderních aplikací má jednostráňovou aplikaci na front-endu, která je primárně napsaná v JavaScriptu. Aplikace často používá architekturu, jako je Angular, React nebo Vue. MSAL.js je jediná knihovna Microsoft Authentication Library, která podporuje jednostránkové aplikace.

• Veřejné klientské aplikace: Aplikace v této kategorii, jako jsou následující typy, vždy přihlašují uživatele:

  • Desktopové aplikace, které volají webová API jménem přihlášených uživatelů
  • Mobilní aplikace
  • Aplikace spuštěné na zařízeních, která nemají prohlížeč, jako jsou aplikace spuštěné v IoT

• Důvěrné klientské aplikace: Mezi aplikace v této kategorii patří:

  • Webové aplikace, které volají webové API
  • Webová rozhraní API, která volají jinou webovou API
  • Aplikace démona, i když jsou implementované jako konzolová služba, jako je démon Linuxu nebo služba pro Windows

Publikum pro přihlášení

Dostupné toky ověřování se liší v závislosti na cílové skupině přihlašování. Některé toky jsou dostupné jenom pro pracovní nebo školní účty. Ostatní jsou k dispozici pro pracovní i školní účty i pro osobní účty Microsoft.

Další informace najdete v tématu Podporované typy účtů.

Typy aplikací

Platforma Microsoft Identity Platform podporuje ověřování pro tyto architektury aplikací:

• Jednostránkové aplikace
• Webové aplikace
• Webová rozhraní API
• Mobilní aplikace
• Nativní aplikace
• Aplikace démonů
• Serverové aplikace

Aplikace používají různé toky ověřování k přihlášení uživatelů a získání tokenů pro volání chráněných rozhraní API.

Jednostránková aplikace

Mnoho moderních webových aplikací je sestaveno jako jednostrákové aplikace na straně klienta. Tyto aplikace používají JavaScript nebo architekturu, jako je Angular, Vue a React. Tyto aplikace běží ve webovém prohlížeči.

Jednostrákové aplikace se liší od tradičních webových aplikací na straně serveru z hlediska charakteristik ověřování. Pomocí platformy Microsoft Identity můžou jednostránkové aplikace přihlásit uživatele a získat tokeny pro přístup ke službám back-end a webovým rozhraním API. Platforma Microsoft Identity Platform nabízí dva typy grantů pro javascriptové aplikace:

MSAL.js (2.x)	MSAL.js (1.x)

Webová aplikace, která přihlásí uživatele

Pro ochranu webové aplikace, která přihlašuje uživatele:

• Pokud vyvíjíte v .NET, používáte ASP.NET nebo ASP.NET Core s middlewarem ASP.NET OpenID Connect. Ochrana prostředku zahrnuje ověření tokenu zabezpečení, které provádějí rozšíření IdentityModel pro .NET, nikoli knihovny MSAL.

• Pokud vyvíjíte v Node.js, použijete uzel MSAL.

Další informace najdete v tématu Webová aplikace, která přihlašuje uživatele.

Webová aplikace, která přihlašuje uživatele a volá webové rozhraní API jménem uživatele

Pokud chcete volat webové rozhraní API z webové aplikace jménem uživatele, použijte tok autorizačního kódu a uložte získané tokeny do mezipaměti tokenů. V případě potřeby msAL aktualizuje tokeny a kontroler bezobslužně získá tokeny z mezipaměti.

Další informace najdete v tématu Webová aplikace, která volá webová rozhraní API.

Desktopová aplikace, která volá webové rozhraní API jménem přihlášeného uživatele

Aby desktopová aplikace volala webové rozhraní API, které přihlašuje uživatele, použijte interaktivní metody získávání tokenů knihovny MSAL. Pomocí těchto interaktivních metod můžete řídit prostředí uživatelského rozhraní přihlašování. Knihovna MSAL používá pro tuto interakci webový prohlížeč.

Existuje další možnost pro aplikace hostované systémem Windows na počítačích připojených buď k doméně Windows, nebo službě Microsoft Entra ID. Tyto aplikace mohou bezobslužně získat token pomocí integrovaného ověřování systému Windows.

Aplikace spuštěné na zařízení bez prohlížeče můžou za uživatele stále volat rozhraní API. Aby se uživatel ověřil, musí se přihlásit na jiném zařízení s webovým prohlížečem. Tento scénář vyžaduje použití device code flow.

I když ho nedoporučujeme používat, je tok uživatelského jména a hesla dostupný ve veřejných klientských aplikacích. Tento tok je stále potřeba v některých scénářích, jako je DevOps.

Použití toku uživatelského jména a hesla omezuje vaše aplikace a už se nepovažuje za bezpečné. Aplikace se například nemůžou přihlásit uživatele, který potřebuje použít vícefaktorové ověřování nebo nástroj podmíněného přístupu v Microsoft Entra ID. Vaše aplikace také nemají prospěch z jednotného přihlašování. Ověřování pomocí toku uživatelského jména a hesla je v rozporu se zásadami moderního ověřování a poskytuje se pouze z důvodů kompatibility se staršími systémy.

Pokud chcete v desktopových aplikacích zachovat mezipaměť tokenů, můžete přizpůsobit serializaci mezipaměti tokenů. Implementací serializace mezipaměti s duálním tokenem můžete využít zpětně kompatibilní a dopředně kompatibilní mezipaměti tokenů.

Další informace najdete v tématu Desktopová aplikace, která volá webová rozhraní API.

Mobilní aplikace, která volá webové rozhraní API jménem interaktivního uživatele

Podobně jako desktopová aplikace volá mobilní aplikace interaktivní metody získávání tokenů msAL k získání tokenu pro volání webového rozhraní API.

MSAL iOS a MSAL Android ve výchozím nastavení používají systémový webový prohlížeč. Můžete je ale nasměrovat tak, aby místo toho používaly vložené webové zobrazení. Na mobilní platformě závisí určitá specifika: iOS nebo Android.

Některé scénáře, jako jsou ty, které zahrnují podmíněný přístup související s ID zařízení nebo registrací zařízení, vyžadují instalaci zprostředkovatele na zařízení. Příklady zprostředkovatelů jsou Microsoft Portál společnosti v Androidu a Microsoft Authenticatoru v Androidu a iOSu.

Další informace najdete v tématu Mobilní aplikace, která volá webová rozhraní API.

Poznámka:

Mobilní aplikace, která používá MSAL iOS nebo MSAL Android, může mít použité zásady ochrany aplikací. Zásady můžou například bránit uživateli v kopírování chráněného textu. Mobilní aplikace je spravovaná službou Intune a intune ji rozpozná jako spravovanou aplikaci. Další informace najdete v Přehledu sady Microsoft Intune App SDK.

Intune App SDK je oddělená od knihoven MSAL a interaguje s MICROSOFT Entra ID samostatně.

Chráněné webové rozhraní API

Koncový bod Microsoft Identity Platform můžete použít k zabezpečení webových služeb, jako je rozhraní RESTful API vaší aplikace. Chráněné webové rozhraní API se volá prostřednictvím přístupového tokenu. Token pomáhá zabezpečit data rozhraní API a ověřovat příchozí požadavky. Volající webového rozhraní API připojí přístupový token v autorizační hlavičce požadavku HTTP.

Pokud chcete chránit ASP.NET nebo ASP.NET core webové rozhraní API, ověřte přístupový token. Pro toto ověření použijete middleware ASP.NET JWT. Ověření provádí knihovna rozšíření IdentityModel pro .NET, nikoli MSAL.NET.

Další informace najdete v tématu Chráněné webové rozhraní API.

Webové rozhraní API, které volá jiné webové rozhraní API jménem uživatele

Aby vaše chráněné webové rozhraní API mohlo volat jiné webové rozhraní API jménem uživatele, vaše aplikace musí získat token pro následné webové rozhraní API. Taková volání se někdy označují jako volání typu služba-služba . Webová rozhraní API, která volají jiná webová rozhraní API, musí poskytovat vlastní serializaci mezipaměti.

Další informace najdete v tématu Webové rozhraní API, které volá webová rozhraní API.

Aplikace démona, která volá webové rozhraní API v názvu démona

Aplikace, které mají dlouhotrvající procesy nebo které pracují bez zásahu uživatele, potřebují také způsob přístupu k zabezpečeným webovým rozhraním API. Taková aplikace může ověřovat a získávat tokeny pomocí identity aplikace. Aplikace prokáže svou identitu pomocí tajného klíče klienta nebo certifikátu.

Můžete napsat takové démonické aplikace, které získávají token pro volající aplikaci pomocí metod získání klientských přihlašovacích údajů v knihovně MSAL. Tyto metody vyžadují tajný klíč klienta, který přidáte do registrace aplikace v Microsoft Entra ID. Aplikace pak sdílí tajemství s nazvaným démonem. Mezi příklady takových tajemství patří hesla aplikací, prohlášení o certifikátu a prohlášení klienta.

Další informace naleznete v tématu Démon aplikace volající webová API.

Scénáře a podporované toky ověřování

Toky ověřování se používají k implementaci scénářů aplikace, které požadují tokeny. Mezi scénáři aplikací a toky ověřování neexistuje mapování 1:1.

Scénáře, které zahrnují získávání tokenů, se také vztahují k autentizačním tokům v OAuth 2.0. Další informace najdete v protokolech OAuth 2.0 a OpenID Connect na platformě Microsoft Identity Platform.

Scénář	Podrobný návod ke scénáři	Proces OAuth 2.0 a povolení	Cílová skupina
	Jednostránková aplikace	Autorizační kód s PKCE	Pracovní nebo školní účty, osobní účty a Azure Active Directory B2C (Azure AD B2C)
	Jednostránková aplikace	Implicitní	Pracovní nebo školní účty, osobní účty a Azure Active Directory B2C (Azure AD B2C)
	Webová aplikace, která přihlašuje uživatele	Autorizační kód	Pracovní nebo školní účty, osobní účty a Azure AD B2C
	Webová aplikace, která volá webová rozhraní API	Autorizační kód	Pracovní nebo školní účty, osobní účty a Azure AD B2C
	Desktopová aplikace, která volá webová rozhraní	Interaktivní pomocí autorizačního kódu s PKCE	Pracovní nebo školní účty, osobní účty a Azure AD B2C
		Integrované ověřování systému Windows	Pracovní nebo školní účty
		Heslo vlastníka prostředku	Pracovní nebo školní účty a Azure AD B2C
	Aplikace bez prohlížeče	Kód zařízení	Pracovní nebo školní účty, osobní účty, ale ne Azure AD B2C
	Mobilní aplikace, která volá webová rozhraní API	Interaktivní pomocí autorizačního kódu s PKCE	Pracovní nebo školní účty, osobní účty a Azure AD B2C
		Heslo vlastníka prostředku	Pracovní nebo školní účty a Azure AD B2C
	Daemon app, která volá webové API	Přihlašovací údaje klienta	Oprávnění jen pro aplikace, která nemají žádného uživatele a používají se jenom v organizacích Microsoft Entra
	Webové rozhraní API, které volá webová rozhraní API	jménem	Pracovní nebo školní účty a osobní účty

Scénáře a podporované platformy a jazyky

Knihovny ověřování Microsoft podporují více platforem:

• .SÍŤ
• .NET Framework
• Java
• JavaScript
• macOS
• Nativní Android
• Nativní iOS
• Node.js
• Krajta

K vytváření aplikací můžete použít také různé jazyky.

Ve sloupci Windows v následující tabulce platí, že kdykoli je zmíněn .NET, je možné také použít .NET Framework. Ta druhá se vynechá, aby se zabránilo zahlcení tabulky.

Scénář	Windows	Operační systém Linux	Macintosh	Ios	Android
Jednostránková aplikace	MSAL.js	MSAL.js	MSAL.js		MSAL.js
Jednostránková aplikace	MSAL.js	MSAL.js	MSAL.js		MSAL.js
Webová aplikace, která přihlašuje uživatele	ASP.NET Core Uzel MSAL	ASP.NET Core Uzel MSAL	ASP.NET Core Uzel MSAL
Webová aplikace, která volá webová rozhraní API	ASP.NET Core + MSAL.NET MSAL v Javě Flask + MSAL Python Uzel MSAL	ASP.NET Core + MSAL.NET MSAL v Javě Flask + MSAL Python Uzel MSAL	ASP.NET Core + MSAL.NET MSAL v Javě Flask + MSAL Python Uzel MSAL
Desktopová aplikace, která volá webová rozhraní	MSAL.NET MSAL v Javě Uzel MSAL	MSAL.NET MSAL v Javě Uzel MSAL	MSAL.NET MSAL v Javě MSAL Python Uzel MSAL MSAL.objc
Mobilní aplikace, která volá webová rozhraní API	MSAL.NET			MSAL.objc	MSAL. Android
Démonická aplikace	MSAL.NET MSAL v Javě Uzel MSAL	MSAL.NET MSAL v Javě Uzel MSAL	MSAL.NET MSAL v Javě Uzel MSAL
Webové rozhraní API, které volá webová rozhraní API	ASP.NET Core + MSAL.NET MSAL v Javě Uzel MSAL	ASP.NET Core + MSAL.NET MSAL v Javě Uzel MSAL	ASP.NET Core + MSAL.NET MSAL v Javě Uzel MSAL

Pro více informací viz knihovny autentizace platformy Microsoft Identity.

Další kroky

Další informace o ověřování najdete tady:

• Ověřování vs. autorizace.
• Přístupové tokeny platformy Microsoft Identity Platform
• Zabezpečení přístupu k aplikacím IoT