Podpora toku ověřování v knihovně Microsoft Authentication Library (MSAL)

Knihovna Microsoft Authentication Library (MSAL) podporuje několik autorizačních grantů a přidružených toků tokenů pro použití různými typy aplikací a scénářů.

Proces ověřování	Umožňuje	Podporované typy aplikací
Autorizační kód	Přihlášení uživatele a přístup k webovým rozhraním API jménem uživatele	Pracovní plocha Mobil Jednostránková aplikace (SPA) (vyžaduje PKCE) Web
Přihlašovací údaje klienta	Přístup k webovým rozhraním API pomocí identity samotné aplikace. Obvykle se používá pro komunikaci mezi servery a automatizované skripty, které nevyžadují žádnou interakci uživatele.	Démon
Kód zařízení	Přihlášení uživatele a přístup k webovým rozhraním API jménem uživatele na vstupních zařízeních s omezeným přístupem, jako jsou inteligentní televizory a zařízení IoT. Používá se také v aplikacích rozhraní příkazového řádku (CLI).	Desktop, Mobile
Implicitní udělení	Přihlášení uživatele a přístup k webovým rozhraním API jménem uživatele Nepoužívejte tento tok – místo toho použijte autorizační kód s PKCE.	* Jednostránkové aplikace (SPA) * Web
On-behalf-of (OBO)	Přístup z nadřazeného webového rozhraní API k podřazenému webovému rozhraní API jménem uživatele. Identita uživatele a delegovaná oprávnění se předávají do podřízeného rozhraní API z upstreamového rozhraní API.	Webové rozhraní API
Uživatelské jméno a heslo (ROPC)	Umožňuje aplikaci přihlásit uživatele přímým zpracováním jeho hesla. Tento tok nepoužívejte.	Desktop, Mobile
Integrované ověřování systému Windows (IWA)	Umožňuje aplikacím na počítačích připojených k doméně nebo Microsoft Entra získat token bez jakékoliv interakce uživatele Pouze pro tenanti pracovních sil.	Desktop, Mobile

Tokeny

Vaše aplikace může používat jeden nebo více toků ověřování. Každý tok používá pro ověřování, autorizaci a aktualizaci tokenů určité typy tokenů a některé také používají autorizační kód.

Proces nebo akce ověřování	Vyžaduje	Identifikační token	Token přístupu	Obnovovací token	Autorizační kód
Tok autorizačního kódu
Přihlašovací údaje klienta			(pouze pro aplikace)
Proud kódu zařízení
Implicitní tok
Tok jménem někoho jiného	přístupový token
Uživatelské jméno a heslo (ROPC)	uživatelské jméno, heslo
Hybridní tok OIDC
Obnovení uplatnění tokenu	obnovovací token

Interaktivní a neinteraktivní ověřování

Některé z těchto toků podporují interaktivní i neinteraktivní získávání tokenů.

• Interactive – Uživatel může být vyzván k zadání vstupu autorizačním serverem. Pokud se například chcete přihlásit, provést vícefaktorové ověřování (MFA) nebo udělit souhlas s více oprávněními pro přístup k prostředkům.
• Neinteraktivní (bezobslužné) – Uživatel nemusí být vyzván k zadání vstupu. Aplikace se pokouší o tzv. "tiché" získání tokenu pomocí metody, při které autorizační server nemusí uživatele vyzvat k zadání vstupu.

Aplikace založená na MSAL by se nejprve měla pokusit získat token bezobslužně a vrátit se k interaktivní metodě pouze v případě, že se nezdaří neinteraktivní pokus. Další informace o tomto vzoru naleznete v tématu Získání a ukládání tokenů do mezipaměti pomocí knihovny MSAL (Microsoft Authentication Library).

Autorizační kód

Udělení autorizačního kódu OAuth 2.0 může používat webové aplikace, jednostránkové aplikace (SPA) a nativní aplikace (mobilní a desktopové) k získání přístupu k chráněným prostředkům, jako jsou webová rozhraní API.

Když se uživatelé přihlásí k webovým aplikacím, obdrží autorizační kód, který může uplatnit pro přístupový token pro volání webových rozhraní API.

Na následujícím diagramu aplikace:

1. Vyžádá si autorizační kód, který byl uplatněn pro přístupový token.
2. Používá přístupový token k volání webového rozhraní API, Microsoft Graphu.

Omezení autorizačního kódu

• Jednostránkové aplikace vyžadují ověřovací klíč pro výměnu kódu (PKCE) při použití grantového toku autorizačního kódu. PKCE je podporováno MSAL.

• Specifikace OAuth 2.0 vyžaduje, abyste k uplatnění přístupového tokenu použili autorizační kód pouze jednou.

  Pokud se pokusíte získat přístupový token vícekrát se stejným autorizačním kódem, vrátí platforma Microsoft Identity Platform chybu podobnou následující. Některé knihovny a architektury za vás automaticky požadují autorizační kód a v takových případech se požadavek na kód vyžádá ručně, dojde také k této chybě.

  AADSTS70002: Error validating credentials. AADSTS54005: OAuth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token.
  

Přihlašovací údaje klienta

Tok přihlašovacích údajů klienta OAuth 2.0 umožňuje přístup k webovým hostovaným prostředkům pomocí identity aplikace. Tento typ udělení se běžně používá pro interakce mezi servery, které musí běžet na pozadí bez okamžité interakce s uživatelem. Tyto typy aplikací se často označují jako démoni nebo služební účty.

Tok udělení přihlašovacích údajů klienta umožňuje webové službě (důvěrnému klientovi) používat vlastní přihlašovací údaje místo zosobnění uživatele k ověření při volání jiné webové služby. V tomto scénáři je klient obvykle středně vrstvenou webovou službou, daemonskou službou nebo webovou stránkou. Pro vyšší úroveň zajištění umožňuje platforma Microsoft Identity Platform také volající službě používat certifikát (místo sdíleného tajného klíče) jako přihlašovací údaje.

Tajné kódy aplikací

Na následujícím diagramu aplikace:

1. Získá token pomocí tajného kódu aplikace nebo přihlašovacích údajů hesla.
2. Používá token k odesílání žádostí o prostředek.

Certifikáty

Na následujícím diagramu aplikace:

1. Získá token pomocí přihlašovacích údajů certifikátu.
2. Používá token k odesílání žádostí o prostředek.

Tyto přihlašovací údaje klienta musí být:

• Zaregistrováno pomocí Microsoft Entra ID
• Předáno při vytváření důvěrného objektu klientské aplikace v kódu

Omezení pro přihlašovací údaje klienta

Důvěrný tok klienta není podporován na mobilních platformách, jako je Android, iOS nebo UPW. Mobilní aplikace jsou považovány za veřejné klientské aplikace, které nemohou zaručit důvěrnost svých přihlašovacích údajů.

Kód zařízení

Tok kódu zařízení OAuth 2.0 umožňuje uživatelům přihlásit se k zařízením s omezeným vstupem, jako jsou inteligentní televizory, zařízení IoT a tiskárny. Interaktivní ověřování pomocí Microsoft Entra ID vyžaduje webový prohlížeč. Pokud zařízení nebo operační systém neposkytuje webový prohlížeč, tok kódu zařízení umožňuje uživateli interaktivně se přihlásit pomocí jiného zařízení, jako je počítač nebo mobilní telefon.

Pomocí toku kódu zařízení aplikace získá tokeny prostřednictvím dvoustupňového procesu navrženého pro tato zařízení a operační systémy. Mezi příklady takových aplikací patří ty, které běží na zařízeních IoT, a nástroje rozhraní příkazového řádku (CLI).

V následujícím diagramu:

1. Pokaždé, když se vyžaduje ověření uživatele, aplikace poskytne kód a požádá uživatele, aby k návštěvě adresy URL (například https://microsoft.com/devicelogin) použil jiné zařízení, jako je smartphone připojený k internetu. Uživateli se pak zobrazí výzva k zadání kódu a v případě potřeby se projde normálním prostředím ověřování, včetně výzev k vyjádření souhlasu a vícefaktorového ověřování.
2. Po úspěšném ověření aplikace příkazového řádku obdrží požadované tokeny prostřednictvím zpětného kanálu a použije je k provádění potřebných volání webového rozhraní API.

Omezení kódu zařízení

• Tok kódu zařízení je k dispozici pouze pro veřejné klientské aplikace.
• Při inicializaci veřejné klientské aplikace v MSAL použijte jeden z těchto formátů autority:
  • Tenant: https://login.microsoftonline.com/{tenant}/, kde {tenant} je ID tenanta nebo název domény přidružený k tenantovi.
  • Pracovní a školní účty: https://login.microsoftonline.com/organizations/.

Implicitní udělení

Implicitní tok udělení se nahradil tokem autorizačního kódu pkCE jako upřednostňovaným a bezpečnějším tokem udělení tokenu pro jednostránkové aplikace na straně klienta (SPA).

Varování

Už se nedoporučuje používat implicitní proces udělování. Pokud vytváříte SPA, použijte místo toho proces autorizačního kódu a PKCE.

Jednostrákové webové aplikace napsané v JavaScriptu (včetně architektur, jako jsou Angular, Vue.js nebo React.js), se stáhnou ze serveru a jejich kód běží přímo v prohlížeči. Vzhledem k tomu, že se jejich kód na straně klienta spouští v prohlížeči a ne na webovém serveru, mají jiné vlastnosti zabezpečení než tradiční webové aplikace na straně serveru. Před zavedením ověřovacího klíče pro výměnu kódu (PKCE) v toku autorizačního kódu používaly SPA implicitní udělovací tok ke zvýšení rychlosti a efektivity při získávání přístupových tokenů.

Tok implicitního udělení OAuth 2.0 umožňuje aplikaci získat přístupové tokeny z platformy Microsoft Identity Platform bez provedení výměny přihlašovacích údajů back-endového serveru. Implicitní tok udělení umožňuje aplikaci přihlásit uživatele, udržovat relaci a získávat tokeny pro jiná webová rozhraní API z kódu JavaScriptu, který stáhne a spustí uživatelský agent (obvykle webový prohlížeč).

Omezení implicitního udělení

Implicitní tok udělení nezahrnuje scénáře aplikací, které používají multiplatformní javascriptové architektury, jako jsou Elektron nebo React Native. Podobné architektury pro různé platformy vyžadují další možnosti pro interakci s nativními desktopovými a mobilními platformami, na kterých běží.

Tokeny vydané prostřednictvím implicitního režimu toku mají omezení délky, protože se vracejí do prohlížeče prostřednictvím adresy URL (kde response_mode je buď query nebo fragment). Některé prohlížeče omezují délku adresy URL na panelu prohlížeče a selžou, když je příliš dlouhá. Proto tyto implicitní tokeny neobsahují groups ani wids nároky.

Jménem (OBO)

Tok ověřování OAuth 2.0 v režimu „on-behalf-of” se používá, když aplikace vyvolá službu nebo webové rozhraní API, které pak potřebuje volat jinou službu nebo webové rozhraní API. Cílem je rozšířit delegovanou identitu uživatele a oprávnění prostřednictvím řetězu požadavků. Aby služba střední vrstvy měla provádět ověřené požadavky na podřízenou službu, musí za uživatele zabezpečit přístupový token z platformy Microsoft Identity Platform.

V následujícím diagramu:

1. Aplikace získá přístupový token pro webové rozhraní API.
2. Klient (webová, desktopová, mobilní nebo jednostránaná aplikace) volá chráněné webové rozhraní API a přidává přístupový token jako nosný token v hlavičce ověřování požadavku HTTP. Webové rozhraní API ověřuje uživatele.
3. Když klient volá webové rozhraní API, požádá webové rozhraní API o jiný token jménem uživatele.
4. Chráněné webové rozhraní API používá tento token k volání podřízeného webového rozhraní API jménem uživatele. Webové rozhraní API také může později požadovat tokeny pro jiná podřízená rozhraní API (ale stále jménem stejného uživatele).

Uživatelské jméno a heslo (ROPC)

Udělení hesla vlastníka prostředku OAuth 2.0 (ROPC) umožňuje aplikaci přihlásit uživatele přímým zpracováním jejich hesla. V desktopové aplikaci můžete k získání tokenu bezobslužně použít tok uživatelského jména a hesla. Při použití aplikace se nevyžaduje žádné uživatelské rozhraní.

Varování

Tok ROPC je zastaralý, použijte bezpečnější tok. Pokyny k migraci najdete v tomto průvodci . ROPC vyžaduje vysoký stupeň důvěryhodnosti a vystavení přihlašovacích údajů. Další informace najdete v tématu Jaké je řešení rostoucího problému s hesly?

Na následujícím diagramu aplikace:

1. Získá token odesláním uživatelského jména a hesla zprostředkovateli identity.
2. Volání webového rozhraní API pomocí tokenu

Pokud chcete získat token bezobslužně na počítačích připojených k doméně s Windows, doporučujeme místo ROPC integrované ověřování systému Windows (IWA ). V jiných scénářích použijte tok kódu zařízení.

Omezení pro ROPC

Následující omezení platí pro aplikace používající tok ROPC:

• Jednotné přihlašování není podporováno.
• Vícefaktorové ověřování (MFA) není podporováno.
  • Před použitím tohoto toku se obraťte na správce tenanta – vícefaktorové ověřování je běžně používaná funkce.
• Podmíněný přístup není podporován.
• ROPC funguje jenom pro pracovní a školní účty.
• RoPC nepodporuje osobní účty Microsoft (MSA).
• ROPC je podporován v desktopových aplikacích .NET a ASP.NET Core.
• ROPC není podporován v aplikacích pro Univerzální platforma Windows (UPW).
• ROPC v Azure AD B2C se podporuje jenom pro místní účty.
  • Informace o ROPC v MSAL.NET a Azure AD B2C najdete v tématu Použití ROPC s Azure AD B2C.

Integrované ověřování systému Windows (IWA)

MSAL podporuje integrované ověřování systému Windows (IWA) pro desktopové a mobilní aplikace, které běží na počítačích s Windows připojených k doméně nebo počítačích s Windows připojených k Microsoft Entra. Pomocí IWA tyto aplikace získávají token bezobslužně bez nutnosti interakce s uživatelským rozhraním uživatelem.

Na následujícím diagramu aplikace:

1. Získá token pomocí integrovaného ověřování systému Windows.
2. Používá token k odesílání žádostí o prostředek.

Omezení pro IWA

Kompatibilita

Integrované ověřování systému Windows (IWA) je povolené pro desktopové aplikace .NET, .NET a Univerzální platformu Windows.

IWA podporuje jenom federované uživatele služby AD FS – uživatele vytvořené ve službě Active Directory a založené na Microsoft Entra ID. Uživatelé vytvoření přímo v Microsoft Entra ID bez zálohování služby Active Directory (spravovaní uživatelé) nemohou použít tento autentizační proces.

Vícefaktorové ověřování (MFA)

Neinteraktivní (tiché) ověřování IWA může selhat, pokud je v tenantovi Microsoft Entra povoleno vícefaktorové ověřování a Microsoft Entra ID vydá výzvu MFA. Pokud IWA selže, měli byste se vrátit k interaktivní metodě ověřování , jak je popsáno výše.

Microsoft Entra ID používá AI k určení, kdy je vyžadováno dvoufaktorové ověřování. Dvoufaktorové ověřování se obvykle vyžaduje, když se uživatel přihlásí z jiné země nebo oblasti, když je připojený k podnikové síti bez použití sítě VPN, a někdy i když je uživatel připojený přes síť VPN. Vzhledem k tomu, že konfigurace a frekvence výzev MFA může být mimo vaši kontrolu jakožto vývojáře, měla by vaše aplikace řádně zvládnout selhání při tichém získávání tokenu metodou IWA.

Omezení URI autority

Autorita, která byla předána při vytváření veřejné klientské aplikace, musí být jedním z těchto:

• https://login.microsoftonline.com/{tenant}/ – Tato autorita označuje aplikaci s jedním tenantem, jejíž přihlašovací cílová skupina je omezena na uživatele v zadaném tenantovi Microsoft Entra. Hodnota {tenant} může být ID tenanta ve formuláři GUID nebo název domény přidružené k tenantovi.
• https://login.microsoftonline.com/organizations/ – Tento identifikátor označuje aplikaci s více tenanty, jejíž přihlašovací cílovou skupinou jsou uživatelé v libovolném tenantovi Microsoft Entra.

Hodnoty autority nesmí obsahovat /common nebo /consumers protože osobní účty Microsoft (MSA) nejsou službou IWA podporovány.

Požadavky na souhlas

Protože IWA představuje tichý tok:

• Uživatel vaší aplikace musel dříve odsouhlasit použití aplikace.

  NEBO

• Správce tenanta musel dříve odsouhlasit všechny uživatele v tenantovi, aby mohli aplikaci používat.

Aby bylo splněno některé z těchto požadavků, musí být splněna jedna z těchto operací:

• Jako vývojář aplikace jste v portálu Azure vybrali Udělení.
• Správce tenanta vybral udělit/odvolat souhlas správce pro {tenant domain} na kartě Oprávnění rozhraní API registrace aplikace v portálu Azure. Viz Přidání oprávnění pro přístup k webovému rozhraní API.
• Poskytli jste uživatelům způsob, jak udělit souhlas s aplikací; viz Souhlas uživatele.
• Poskytli jste správci tenanta způsob, jak udělit souhlas s aplikací; viz souhlas správce.

Další informace o souhlasu najdete v tématu Oprávnění a souhlas.

Další krok

Seznamte se se získáním a ukládáním tokenů používaných v těchto tocích do mezipaměti:

Získání a ukládání tokenů do mezipaměti pomocí knihovny Microsoft Authentication Library (MSAL)