Sdílet prostřednictvím

Microsoft Identity Platform a OAuth 2.0 heslové údaje vlastníka zdroje

  • Článek

Platforma Microsoft Identity Platform podporuje přihlašovací údaje vlastníka prostředku OAuth 2.0 (ROPC) k udělení, což umožňuje aplikaci přihlásit se uživatele přímým zpracováním hesla. Tento článek popisuje, jak programovat přímo proti protokolu ve vaší aplikaci. Pokud je to možné, doporučujeme místo toho použít podporované knihovny MSAL (Microsoft Authentication Library) k získání tokenů a volání zabezpečených webových rozhraní API. Podívejte se také na ukázkové aplikace , které používají MSAL.

Varování

Společnost Microsoft doporučuje, abyste nepoužívali tok ROPC; není kompatibilní s vícefaktorovým ověřováním (MFA). Ve většině scénářů jsou k dispozici a doporučeny bezpečnější alternativy. Tento tok vyžaduje velmi vysoký stupeň důvěryhodnosti v aplikaci a nese rizika, která nejsou přítomna v jiných tocích. Tento tok byste měli použít jenom tehdy, když nejsou dostupné bezpečnější toky.

Důležitý

  • Platforma Microsoft Identity Platform podporuje pouze grant ROPC v rámci tenantů Microsoft Entra, nikoli osobních účtů. To znamená, že musíte použít koncový bod specifický pro tenanta (https://login.microsoftonline.com/{TenantId_or_Name}) nebo koncový bod organizations.
  • Osobní účty pozvané do tenanta Microsoft Entra nemůžou používat tok ROPC.
  • Účty, které nemají hesla, se nemůžou přihlásit pomocí ROPC, což znamená, že s tímto tokem nebudou fungovat funkce, jako je přihlášení přes SMS, FIDO a aplikace Authenticator. Pokud vaše aplikace nebo uživatelé vyžadují tyto funkce, použijte jiný typ udělení než ROPC.
  • Pokud uživatelé potřebují k přihlášení k aplikaci použít vícefaktorové ověřování (MFA), budou místo toho zablokovaní.
  • ROPC se nepodporuje v scénářích federace hybridních identit (například ID Microsoft Entra a AD FS používané k ověřování místních účtů). Pokud jsou uživatelé přesměrováni na celou stránku k lokálnímu zprostředkovateli identity, Microsoft Entra ID není schopný otestovat uživatelské jméno a heslo pro daného zprostředkovatele identity. Delegované ověřování je však podporováno pomocí ROPC.
  • Výjimkou ve scénáři federace hybridní identity může být následující: Zásada Home Realm Discovery s nastavením AllowCloudPasswordValidation na TRUE umožní, aby ROPC tok fungoval pro federované uživatele, když je místní heslo synchronizováno do cloudu. Další informace najdete v tématu Povolení přímého ověřování ROPC federovaných uživatelů pro starší verze aplikací.
  • Tok ROPC nepodporuje hesla s počátečními nebo koncovými prázdnými znaky.

Jak migrovat z ROPC

S tím, jak se vícefaktorové ověřování stává běžnější, některá webová rozhraní API Microsoftu budou přijímat přístupové tokeny pouze tehdy, pokud splnily požadavky tohoto ověřování. Aplikace a testovací rigy, které se spoléhají na ROPC, budou uzamčeny. Microsoft Entra buď nevydá token, nebo prostředek žádost odmítne.

Pokud k získání tokenů k volání chráněných podřízených rozhraní API používáte ROPC, migrujte na zabezpečenou strategii získávání tokenů.

Pokud je k dispozici kontext uživatele

Pokud koncový uživatel potřebuje získat přístup k prostředku, měla by klientská aplikace, která jménem jedná, používat formu interaktivního ověřování. Koncovému uživateli může být výzva pro vícefaktorové ověřování předložena pouze v prohlížeči.

  • Pro webové aplikace:
  • Webová rozhraní API nemohou spustit prohlížeč. Místo toho musí vrátit výzvu zpět do klientské aplikace. Podrobnosti najdete v webových API a výzvách uživatelům ve webových API.
  • Desktopové aplikace by měly používat ověřování založené na zprostředkovatelích. Zprostředkovatelé používají ověřování založené na prohlížeči, aby mohli vynutit vícefaktorové ověřování a dosáhnout co nejvyšší úrovně zabezpečení.
  • Mobilní aplikace by také měly být nakonfigurované tak, aby používaly ověřování založené na zprostředkovatele (Authenticator, Portál společnosti).

Pokud kontext uživatele není k dispozici

Příklady scénářů, ve kterých není zapojen žádný uživatelský kontext, avšak mezi ně patří, ale nejsou omezeny na následující:

  • Skript spuštěný jako součást CI potrubí.
  • Služba, která potřebuje zavolat prostředek vlastním jménem, bez uživatelských informací.

Vývojáři aplikací by měli používat ověřování instančního objektu, což je znázorněno v ukázkách démona . Vícefaktorové ověřování se nevztahuje na služební principály.

Existuje několik způsobů, jak se autentizovat jako služební principál:

  • Pokud vaše aplikace běží v infrastruktuře Azure, použijte spravované identity. Spravovaná identita eliminuje režii při údržbě a obměně tajných kódů a certifikátů.
  • Pokud vaše aplikace běží v systému spravovaném jiným zprostředkovatelem identity kompatibilním s OAuth2, jako je GitHub, použijte přihlašovací údaje federované identity.
  • Pokud nemůžete použít spravovanou identitu nebo federovanou identitu, použijte přihlašovací údaje certifikátu.

Varování

Nepoužívejte ověřování služebního objektu, pokud je k dispozici kontext uživatele. Přístup jen pro aplikace je přirozeně vysoce oprávněný, často uděluje přístup v rámci celého tenanta a potenciálně umožňuje škodlivému aktérovi přístup k zákaznickým datům pro libovolného uživatele.

Diagram protokolu

Následující diagram znázorňuje tok ROPC.

diagram znázorňující tok přihlašovacích údajů vlastníka prostředku

Žádost o autorizaci

Proud ROPC je jeden požadavek; posílá identifikaci klienta a přihlašovací údaje uživatele zprostředkovateli identity a na oplátku obdrží tokeny. Než to uděláte, musí si klient vyžádat e-mailovou adresu uživatele (UPN) a heslo. Ihned po úspěšném požadavku by měl klient bezpečně zahodit přihlašovací údaje uživatele z paměti. Nikdy je to nesmí zachránit.

// Line breaks and spaces are for legibility only.  This is a public client, so no secret is required.

POST {tenant}/oauth2/v2.0/token
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=user.read%20openid%20profile%20offline_access
&username=MyUsername@myTenant.com
&password=SuperS3cret
&grant_type=password
Parametr Podmínka Popis
tenant Povinný Tenant adresáře, ke kterému chcete uživatele přihlásit. Tenant může být ve formátu GUID nebo popisného názvu. Jeho parametr však nelze nastavit na common nebo consumers, ale může být nastaven na organizations.
client_id Povinný ID aplikace (klienta), které stránka Registrace aplikací v Centru pro správu Microsoft Entra přiřadila k vaší aplikaci.
grant_type Požadovaný Musí být nastavena na password.
username Požadovaný E-mailová adresa uživatele.
password Požadovaný Heslo uživatele.
scope Doporučený Seznam rozsahů nebo oprávnění oddělených mezerami , které aplikace vyžaduje. V interaktivním toku musí správce nebo uživatel s těmito obory předem souhlasit.
client_secret Někdy se vyžaduje Pokud je vaše aplikace veřejným klientem, není možné zahrnout client_secret nebo client_assertion. Pokud je aplikace důvěrným klientem, musí být zahrnuta.
client_assertion Někdy se vyžaduje Jiná forma client_secret, vygenerovaná pomocí certifikátu. Další informace naleznete v přihlašovacích údajích certifikátu .

Úspěšná odpověď na ověření

Následující příklad ukazuje úspěšnou odpověď tokenu:

{
    "token_type": "Bearer",
    "scope": "User.Read profile openid email",
    "expires_in": 3599,
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD..."
}
Parametr Formát Popis
token_type Řetězec Vždy je nastavená na Bearer.
scope Řetězce oddělené mezerami Pokud byl vrácen přístupový token, tento parametr vypíše obory, pro které je přístupový token platný.
expires_in Int Počet sekund, pro které je zahrnutý přístupový token platný.
access_token Neprůzný řetězec Vydáno pro obory , které byly požadovány.
id_token JWT Vydáno, pokud původní scope parametr zahrnoval rozsah openid.
refresh_token Neprůzný řetězec Vydáno, pokud původní scope parametr zahrnoval offline_access.

Obnovovací token můžete použít k získání nových přístupových a obnovovacích tokenů prostřednictvím stejného procesu popsaného v dokumentaci k procesu OAuth Code.

Varování

Nepokoušejte se ověřovat ani číst tokeny pro žádné rozhraní API, které nevlastníte, včetně tokenů v tomto příkladu, ve vašem kódu. Tokeny pro služby Microsoftu můžou používat speciální formát, který se neověří jako JWT a může být také zašifrován pro uživatele s uživatelským účtem (účet Microsoft). Přestože je čtení tokenů užitečným nástrojem pro ladění a učení, nepřebídejte závislosti na tomto kódu ani nepředpokládejte konkrétní údaje o tokenech, které nejsou určené pro rozhraní API, které řídíte.

Chybová odpověď

Pokud uživatel nezadá správné uživatelské jméno nebo heslo nebo klient neobdržel požadovaný souhlas, ověření se nezdaří.

Chyba Popis Akce klienta
invalid_grant Ověření se nezdařilo. Přihlašovací údaje byly nesprávné nebo klient nemá souhlas s požadovanými obory. Pokud obory nejsou uděleny, vrátí se consent_required chyba. Aby se tato chyba vyřešila, klient by měl uživateli odeslat interaktivní výzvu pomocí webového zobrazení nebo prohlížeče.
invalid_request Požadavek byl nesprávně sestaven. Typ grantu není podporován v kontextech ověřování /common nebo /consumers. Místo toho použijte /organizations nebo ID tenanta.

Víc se uč

Příklad implementace toku ROPC najdete v ukázkové konzolové aplikace .NET kódu na GitHubu.