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

  • Článek

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

Tok 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 * Plochy
* Mobilní
* Jednostránková aplikace (SPA) (vyžaduje PKCE)
* Webové
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í interakci uživatele. Daemon
Kód zařízení Přihlášení uživatelů a přístup k webovým rozhraním API jménem uživatele na zařízeních s omezeným vstupem, jako jsou inteligentní televizory a zařízení Internetu věcí (IoT). Používá se také v aplikacích rozhraní příkazového řádku (CLI). Stolní počítač, mobilní zařízení
Implicitní udělení Přihlášení uživatele a přístup k webovým rozhraním API jménem uživatele Implicitní tok udělení se už nedoporučuje – místo toho použijte autorizační kód s ověřovacím klíčem pro výměnu kódu (PKCE). * Jednostránková aplikace (SPA)
* Webové
On-behalf-of (OBO) Přístup z "upstreamového" webového rozhraní API k "podřízené" webové 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 nadřazeného rozhraní API. Webové rozhraní API
Uživatelské jméno a heslo (ROPC) Umožňuje aplikaci přihlásit uživatele přímou manipulací s jeho heslem. Tok ROPC se nedoporučuje. Stolní počítač, mobilní zařízení
Integrované ověřování Systému Windows (IWA) Umožňuje aplikacím v doméně nebo Microsoft Entra ID připojených počítačích získat token bezobslužně (bez zásahu uživatele s uživatelským rozhraním). Stolní počítač, mobilní zařízení

Tokeny

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

Tok nebo akce ověřování Vyžaduje Token ID Přístupový token Obnovte token Autorizační kód
Tok autorizačního kódu ✅ ✅ ✅ ✅
Přihlašovací údaje klienta ✅ (jenom aplikace)
Tok kódu zařízení ✅ ✅ ✅
Implicitní tok ✅ ✅
Tok On-Behalf-Of Přístupový token ✅ ✅ ✅
Uživatelské jméno a heslo (ROPC) Uživatelské jméno, heslo ✅ ✅ ✅
Hybridní tok OIDC ✅ ✅
Obnovení uplatnění tokenu Obnovte token ✅ ✅ ✅

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

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

  • Interaktivní – uživatel může být vyzván k zadání vstupu autorizačním serverem. Můžete se například přihlásit, provést vícefaktorové ověřování (MFA) nebo udělit souhlas s více oprávněními k přístupu k prostředkům.
  • Neinteraktivní – uživatel nemusí být vyzván k zadání vstupu. Aplikace se také označuje jako získání tichého tokenu a pokouší se získat token pomocí metody, ve které autorizační server nemusí uživatele vyzvat k zadání.

Vaše aplikace založená na MSAL by se měla nejprve pokusit získat token bezobslužně a vrátit se k interaktivní metodě pouze v případě, že neinteraktivní pokus selže. Další informace o tomto vzoru najdete v tématu Získání tokenů 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 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, aplikace obdrží autorizační kód, který může uplatnit za přístupový token pro volání webových rozhraní API.

Diagram toku autorizačního kódu

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 Microsoft Graph.

Omezení autorizačního kódu

  • Jednostránkové 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 ). Služba MSAL podporuje PKCE.

  • 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í 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 bude mít za následek také ruční žádost o kód.

    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 prostředkům hostovaným na webu 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žít 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 webová služba střední vrstvy, služba démona nebo web. Pro vyšší úroveň záruky Microsoft identity platform také umožňuje 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í

Diagram důvěrného klienta s heslem

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 vytváření žádostí o prostředky.

Certifikáty

Diagram důvěrného klienta s certifikátem

V předchozím diagramu aplikace:

  1. Získá token pomocí přihlašovacích údajů certifikátu.
  2. Použije token k vytváření žádostí o prostředky.

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

  • Zaregistrováno u Azure AD.
  • Předává se při vytváření objektu důvěrné klientské aplikace v kódu.

Omezení přihlašovacích údajů 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é nejsou schopné zaručit důvěrnost ověřovacích tajných kódů.

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 použít k interaktivnímu přihlášení jiné zařízení, například počítač nebo mobilní telefon.

Pomocí toku kódu zařízení získá aplikace tokeny prostřednictvím dvoustupňového procesu navrženého pro tato zařízení a operační systémy.

Diagram toku kódu zařízení

V předchozím diagramu:

  1. Kdykoli je vyžadováno ověření uživatele, aplikace poskytne kód a požádá uživatele, aby k návštěvě adresy URL použil jiné zařízení, jako je smartphone připojený k internetu (například https://microsoft.com/devicelogin). Uživatel je pak vyzván k zadání kódu a pokračuje normálním prostředím ověřování, včetně výzev k vyjádření souhlasu a v případě potřeby vícefaktorového ověřování.
  2. Po úspěšném ověření obdrží žádající aplikace požadované tokeny z Microsoft identity platform a použije je k provádění potřebných volání webového rozhraní API.

Omezení pro kód 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 buď 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 s pkCE jako upřednostňovaným a bezpečnějším tokem udělení tokenů pro jednostránkové aplikace (SPA) na straně klienta. Pokud vytváříte SPA, použijte místo toho tok autorizačního kódu s PKCE.

Jednostránkové webové aplikace napsané v JavaScriptu (včetně architektur, jako jsou Angular, Vue.js nebo React.js) se stahují ze serveru a jejich kód běží přímo v prohlížeči. Vzhledem k tomu, že jejich kód na straně klienta běží v prohlížeči a ne na webovém serveru, mají jiné charakteristiky zabezpečení než tradiční webové aplikace na straně serveru. Před dostupností ověřovacího klíče pro výměnu kódu (PKCE) pro tok autorizačního kódu používaly tok implicitního udělení pro lepší odezvu a efektivitu při získávání přístupových tokenů.

Tok implicitního udělení OAuth 2 umožňuje aplikaci získat přístupové tokeny z Microsoft identity platform bez provádění výměny přihlašovacích údajů back-endového serveru. Tok implicitního udělení oprávnění umožňuje aplikaci přihlásit se k uživateli, 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).

Diagram toku implicitního udělení

Omezení pro implicitní udělení

Implicitní tok udělení nezahrnuje scénáře aplikací, které používají multiplatformní rozhraní JavaScriptu, jako jsou Electron nebo React Native. Takové multiplatformní architektury vyžadují další funkce pro interakci s nativními desktopovými a mobilními platformami, na kterých běží.

Tokeny vydané prostřednictvím režimu implicitního toku mají omezení délky , protože se vrací do prohlížeče v adrese URL (kde response_mode je buď nebo queryfragment). Některé prohlížeče omezují délku adresy URL na panelu prohlížeče, a pokud je adresa příliš dlouhá, selžou. Tyto implicitní tokeny toku tedy neobsahují groups deklarace identity ani wids .

On-behalf-of (OBO)

Tok ověřování OAuth 2 jménem se používá, když aplikace vyvolá službu nebo webové rozhraní API, které pak potřebuje volat jinou službu nebo webové rozhraní API s využitím delegované identity uživatele a oprávnění, která se musí rozšířit v řetězu požadavků. Aby služba střední vrstvy zasílala ověřené požadavky na podřízenou službu, potřebuje zabezpečit přístupový token z Microsoft identity platform jménem žádajícího uživatele.

Diagram toku on-behalf-of

V předchozím diagramu:

  1. Aplikace získá přístupový token pro webové rozhraní API.
  2. Klient (webová, desktopová, mobilní nebo jednostránková aplikace) volá chráněné webové rozhraní API a do ověřovací hlavičky požadavku HTTP přidá přístupový token jako nosný token. Webové rozhraní API ověří uživatele.
  3. Když klient volá webové rozhraní API, webové rozhraní API si vyžádá 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 může později také 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)

Upozornění

Tok přihlašovacích údajů vlastníka prostředku (ROPC) se už nedoporučuje. ROPC vyžaduje vysoký stupeň důvěryhodnosti a odhalení přihlašovacích údajů. ROPC používejte jenom v případě, že není možné použít bezpečnější tok. Další informace najdete v tématu Jaké je řešení rostoucího problému s hesly?.

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

V některých scénářích aplikací, jako je DevOps, může být ROPC užitečné, ale měli byste se mu vyhnout v jakékoli aplikaci, ve které poskytujete interaktivní uživatelské rozhraní pro přihlašování uživatelů.

Diagram toku uživatelského jména a hesla

V předchozím diagramu aplikace:

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

Pokud chcete získat token bezobslužně na počítačích s Windows připojených k doméně, 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, které používají tok ROPC:

  • Jednotné přihlašování se nepodporuje.
  • Vícefaktorové ověřování (MFA) se nepodporuje.
    • Než tento tok použijete, obraťte se na správce tenanta – běžně se používá vícefaktorové ověřování.
  • Podmíněný přístup se nepodporuje.
  • ROPC funguje jenom pro pracovní a školní účty.
  • RoPC nepodporuje osobní účty Microsoft (MSA).
  • ROPC se podporuje v desktopových a .NET aplikacích .NET.
  • ROPC se nepodporuje v aplikacích Univerzální platforma Windows (UPW).
  • ROPC v Microsoft Entra Externí ID se podporuje jenom pro místní účty.

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

Poznámka

Integrované ověřování systému Windows bylo nahrazeno spolehlivějším způsobem bezobslužného získávání tokenů – WAM. WAM může bezobslužně přihlásit aktuálního uživatele Windows. Tento pracovní postup nevyžaduje složité nastavení a funguje dokonce i pro osobní účty (Microsoft). Windows Broker (WAM) interně vyzkouší několik strategií, jak získat token pro aktuálního uživatele Windows, včetně IWA a uplatnění prt. Tím se eliminuje většina omezení IWA.

Knihovna 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 Microsoft Entra ID. Pomocí IWA tyto aplikace získají token bezobslužně, aniž by vyžadovaly interakci uživatele s uživatelským rozhraním.

Diagram integrovaného ověřování systému Windows

V předchozím diagramu aplikace:

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

Omezení pro IWA

  • Kompatibilita. Integrované ověřování Windows (IWA) je povolené pro desktopové aplikace .NET, .NET a aplikace Univerzální platforma Windows (UPW). IWA podporuje pouze uživatele federované službou AD FS – uživatele vytvořené ve službě Active Directory a podporované Microsoft Entra ID. Uživatelé vytvoření přímo v Microsoft Entra ID bez zálohování služby Active Directory (spravovaní uživatelé) nemůžou tento tok ověřování používat.
  • 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 vystavil výzvu vícefaktorového ověřování. 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 pomocí umělé inteligence určí, kdy se vyžaduje dvojúrovňové ověřování. Dvojúrovňové ověřování se obvykle vyžaduje, když se uživatel přihlašuje z jiné země nebo oblasti, při připojení k podnikové síti bez použití sítě VPN a někdy, když je připojený prostřednictvím sítě 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 předaná při vytváření veřejné klientské aplikace musí být jedna z těchto možností:
    • https://login.microsoftonline.com/{tenant}/– Tato autorita označuje aplikaci s jedním tenantem, jejíž cílová skupina přihlašování je omezená na uživatele v zadaném Microsoft Entra ID tenantovi. Hodnotou {tenant} může být ID tenanta ve formátu 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íž přihlašovací cílovou skupinou jsou uživatelé v libovolném Microsoft Entra ID tenantovi.
  • Osobní účty. Hodnoty autority nesmí obsahovat /common nebo /consumers proto, že služba IWA nepodporuje osobní účty Microsoft (MSA).
  • Požadavky na souhlas. Vzhledem k tomu, že IWA je bezobslužný tok, musí uživatel vaší aplikace předem vyjádřit souhlas s používáním aplikace, nebo musí správce tenanta předem vyjádřit souhlas s používáním aplikace všem uživatelům v tenantovi. Aby bylo splněno některé z těchto požadavků, musí být dokončena jedna z těchto operací:

Další kroky

Teď, když jste si prostudovali toky ověřování podporované nástrojem MSAL, se dozvíte, jak získat tokeny používané v těchto tocích a jejich ukládání do mezipaměti.