Share via

Podpora toku ověřování v MSAL

  • Článek

Knihovna MSAL (Microsoft Authentication Library) 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áři.

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 Desktop
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í žádnou interakci uživatele. Daemon
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 Implicitní tok udělení se už nedoporučuje – místo toho použijte autorizační kód s PKCE. * Jednostránkové aplikace (SPA)
* Webová
On-behalf-of (OBO) Přístup z "upstreamového" webového rozhraní API na "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 upstreamového rozhraní API. Webové rozhraní API
Uživatelské jméno a heslo (ROPC) Umožňuje aplikaci přihlásit se k uživateli přímým zpracováním hesla. Tok ROPC se nedoporučuje. Desktop, Mobile
Integrované ověřování systému Windows (IWA) Umožňuje aplikacím v doméně nebo počítačích připojených k Microsoft Entra získat token bezobslužně (bez zásahu uživatelského rozhraní od uživatele). 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.

Tok nebo akce ověřování Vyžaduje Token ID Token přístupu Obnovovací token Autorizační kód
Tok autorizačního kódu Tok ověřování funguje pro token ID Tok ověřování funguje pro přístupový token. Tok ověřování funguje pro obnovovací token Autorizační kód funguje
Přihlašovací údaje klienta Tok ověřování funguje pro přístupový token. (jenom aplikace)
Tok kódu zařízení Tok ověřování funguje pro token ID Tok ověřování funguje pro přístupový token. Tok ověřování funguje pro obnovovací token
Implicitní tok Tok ověřování funguje pro token ID Tok ověřování funguje pro přístupový token.
Tok On-Behalf-Of přístupový token Tok ověřování funguje pro token ID Tok ověřování funguje pro přístupový token. Tok ověřování funguje pro obnovovací token
Uživatelské jméno a heslo (ROPC) uživatelské jméno, heslo Tok ověřování funguje pro token ID Tok ověřování funguje pro přístupový token. Tok ověřování funguje pro obnovovací token
Hybridní tok OIDC Tok ověřování funguje pro token ID Autorizační kód funguje
Obnovení uplatnění tokenu obnovovací token Tok ověřování funguje pro token ID Tok ověřování funguje pro přístupový token. Tok ověřování funguje pro 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 také pokusí 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ůž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.

V 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.

Diagram toku autorizačního kódu

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, 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 procesy démon nebo účty služeb.

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

Diagram důvěrného klienta s heslem

Certifikáty

V 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.

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

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.

Diagram toku kódu zařízení

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). Už se nedoporučuje používat implicitní tok udělení. 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ů.

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 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).

Diagram implicitního toku udělení

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 adresou 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 toku ověřování OAuth 2.0 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).

Diagram toku jménem uživatele

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

Upozorňující

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

Udělení přihlašovacích údajů vlastníka prostředku OAuth 2.0 (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 tomu vyhnout v jakékoli aplikaci, ve které poskytujete interaktivní uživatelské rozhraní pro přihlašování uživatelů.

V 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

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

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.

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

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

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ý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 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 frekvence konfigurace a výzvy MFA může 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 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/ – Tato autorita označuje aplikaci s více tenanty, jejíž přihlašovací cílová skupina je uživateli 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 je 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 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 Souhlas uživatele.
  • Poskytli jste správci tenanta způsob, jak udělit souhlas s aplikací; viz Správa istrator souhlas.

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)