Toky ověřování podporované v MSAL

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

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.

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í – Uživatel nemusí být vyzván k zadání vstupu. Aplikace se také pokouší získat token pomocí metody, ve 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ůžou používat webové aplikace, jednostránkové aplikace (SPA) a nativní (mobilní a desktopové) aplikace pro 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.

V předchozí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, jako je Například Microsoft Graph.

Omezení autorizačního kódu

• Jednostránky aplikace vyžadují při použití toku udělení autorizačního kódu ověřovací klíč pro výměnu kódu (PKCE ). Knihovna PKCE je podporována knihovnou MSAL.

• Specifikace OAuth 2.0 vyžaduje použití autorizačního kódu k uplatnění přístupového tokenu 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í. Mějte na paměti, že některé knihovny a architektury za vás automaticky požadují autorizační kód a v takových případech ručně požadavek na kód způsobí také tuto chybu.

  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 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 (S2S), které musí běžet na pozadí bez okamžité interakce uživatele. Tyto typy aplikací se často označují jako démony nebo služby.

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 webovou službou střední vrstvy, službou démona nebo webem. 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í

V předchozím diagramu aplikace:

1. Získá token pomocí tajného kódu aplikace nebo přihlašovacích údajů hesla.
2. Použije token k provádění požadavků na prostředky.

Certifikáty

V předchozím diagramu aplikace:

1. Získá token pomocí přihlašovacích údajů certifikátu.
2. Použije token k provádění požadavků na prostředky.

Tento typ přihlašovacích údajů klienta musí být:

• Zaregistrováno v Azure AD.
• Předán 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 Univerzální platforma Windows (UPW). Mobilní aplikace jsou považovány za veřejné klientské aplikace, které nemohou zaručit důvěrnost tajných kódů ověřování.

Kód zařízení

Tok kódu zařízení OAuth 2 umožňuje uživatelům přihlásit se k zařízením s omezeným vstupem, jako jsou inteligentní televizory, zařízení Internetu věcí (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 interaktivní přihlášení 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.

V předchozí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. V případě potřeby se uživateli zobrazí výzva k zadání kódu a pokračuje normálním ověřováním, včetně výzev k vyjádření souhlasu a vícefaktorového ověřování.
2. Po úspěšném ověření obdrží žádající aplikace požadované tokeny z platformy Microsoft Identity Platform 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:
  • Na základě tenanta: https://login.microsoftonline.com/{tenant}/, kde {tenant} je identifikátor GUID představující 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í udělení bylo nahrazeno 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). Pokud vytváříte spa, použijte místo toho tok autorizačního kódu s 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 dostupností ověřovacího klíče pro tok kódu PKCE (Proof Key for Code Exchange) pro tok autorizačního kódu používaly spA implicitní tok udělení, aby se zlepšila rychlost odezvy a efektivita při získávání přístupových tokenů.

Implicitní tok udělení OAuth 2 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 se uživatele, udržovat relaci a získávat tokeny pro jiná webová rozhraní API z kódu JavaScriptu staženého a spuštěného uživatelským agentem (obvykle webovým prohlížečem).

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 vrátí do prohlížeče v adrese URL (kde response_mode je nebo queryfragment). Některé prohlížeče omezují délku adresy URL na panelu prohlížeče a při příliš dlouhém zobrazení selžou. Proto tyto implicitní tokeny toku neobsahují groups ani wids deklarace identity.

On-behalf-of (OBO)

Tok toku ověřování OAuth 2 se používá, když aplikace vyvolá službu nebo webové rozhraní API, které zase potřebuje volat jinou službu nebo webové rozhraní API pomocí delegované identity uživatele a oprávnění, která je potřeba rozšířit 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í zabezpečit přístupový token z platformy Microsoft Identity Platform jménem žádajícího uživatele.

V předchozí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, webové rozhraní API požádá jménem uživatele o další token.
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í přihlašovacích údajů vlastníka prostředku OAuth 2 (ROPC) umožňuje aplikaci přihlásit se uživatele přímým zpracováním 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í.

Některé scénáře aplikací, jako je DevOps, můžou být užitečné, ale měli byste se mu vyhnout v jakékoli aplikaci, ve které zadáte interaktivní uživatelské rozhraní pro přihlášení uživatele.

V předchozím diagramu aplikace:

1. Získá token odesláním uživatelského jména a hesla zprostředkovateli identity.
2. Volá webové 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 použít Správce webových účtů (WAM ). 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 se podporuje v desktopových aplikacích .NET a .NET.
• ROPC není podporován v aplikacích pro Univerzální platforma Windows (UPW).
• ROPC v Microsoft Entra Externí ID se podporuje jenom pro místní účty.
  • Informace o ROPC v MSAL.NET a Microsoft Entra Externí ID naleznete v tématu Přihlašovací údaje vlastníka prostředku (ROPC) s 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.

V předchozím diagramu aplikace:

1. Získá token pomocí integrovaného ověřování systému Windows.
2. Použije token k provádění požadavků na prostředky.

Omezení pro IWA

• Kompatibilita. Integrované ověřování systému Windows (IWA) je povolené pro desktopové aplikace .NET, .NET a Univerzální platforma Windows (UPW). IWA podporuje pouze federované uživatele ADFS – 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ých uživatelů) nemůžou tento tok ověřování použít.
• Vícefaktorové ověřování (MFA) Neinteraktivní (tiché) ověřování IWA může selhat, pokud je v tenantovi Microsoft Entra ID povolené 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 když je připojený přes síť VPN. Vzhledem k tomu, že konfigurace vícefaktorového ověřování a frekvence výzev můžou být mimo vaši kontrolu jako vývojář, měla by vaše aplikace řádně zvládnout selhání získání tichého tokenu IWA.
• Omezení identifikátoru 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 omezená na uživatele v zadaném tenantovi Microsoft Entra ID. 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/ – Tato autorita označuje aplikaci s více tenanty, jejíž cílovou skupinou přihlašování jsou uživatelé v libovolném tenantovi Microsoft Entra ID.
• Osobní účty. Hodnoty autorit nesmí obsahovat /common nebo /consumers protože osobní účty Microsoft (MSA) nejsou podporovány IWA.
• Požadavky na souhlas. Vzhledem k tomu, že IWA je tichý tok, musí uživatel vaší aplikace 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 sami na webu Azure Portal vybrali Možnost Udělení .
  • Správce tenanta vybral na kartě Oprávnění rozhraní API registrace aplikace na webu Azure Portal souhlas správce udělit nebo odvolat souhlas správce pro {tenant domain}. 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 Přehled oprávnění a souhlasu na platformě Microsoft Identity Platform.
  • Poskytli jste správci tenanta způsob, jak udělit souhlas s aplikací; Viz Přehled oprávnění a souhlasu na platformě Microsoft Identity Platform.

Další kroky

Teď, když jste zkontrolovali toky ověřování podporované službou MSAL, se dozvíte o získání a ukládání tokenů používaných v těchto tocích do mezipaměti.