Přihlašovací údaje vlastníka prostředku Microsoft Identity Platform a OAuth 2.0

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

Upozorňující

Microsoft doporučuje nepoužívat tok ROPC. 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 v případě, že jiné bezpečnější toky nejsou přijatelné.

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 organizations koncový bod.
  • 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í do aplikace použít vícefaktorové ověřování (MFA), budou místo toho zablokováni.
  • ROPC se nepodporuje ve scénářích federace hybridních identit (například ID Microsoft Entra a AD FS sloužící k ověřování místních účtů). Pokud jsou uživatelé kompletně přesměrováni na místního poskytovatele identit, služba Microsoft Entra ID není schopna u tohoto poskytovatele identit otestovat uživatelské jméno a heslo. Předávací ověřování se však u ROPC podporuje.
  • Výjimkou scénáře hybridní federace identit je následující: Zásady zjišťování domovské sféry s povolenou funkcí AllowCloudPasswordValidation nastavenou na HODNOTU TRUE umožní toku ROPC fungovat pro federované uživatele, když se místní heslo synchronizuje 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.

Diagram protokolu

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

Diagram showing the resource owner password credential flow

Žádost o autorizaci

Tok ROPC je jeden požadavek; odešle identifikaci klienta a přihlašovací údaje uživatele zprostředkovateli identity a obdrží tokeny ve vrácení. 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 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í účastníci 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 Požaduje se ID aplikace (klienta), které centrum pro správu Microsoft Entra – Registrace aplikací stránku přiřazenou k vaší aplikaci.
grant_type Požaduje se Musí být nastavena na passwordhodnotu .
username Požaduje se E-mailová adresa uživatele.
password Požaduje se Heslo uživatele.
scope Doporučené Seznam oborů 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é ji client_secretclient_assertion zahrnout. Pokud je aplikace důvěrným klientem, musí být zahrnuta.
client_assertion Někdy se vyžaduje Jiná forma vygenerovaného client_secretpomocí certifikátu. Další informace najdete v tématu Přihlašovací údaje 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 String Vždy nastaveno na Bearerhodnotu .
scope Řádkování oddělených řetězců 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 požadované obory .
id_token JWT Vydáno, pokud původní scope parametr zahrnoval openid obor.
refresh_token Neprůzný řetězec Vydáno, pokud byl součástí offline_accesspůvodního scope parametru .

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

Upozorňující

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 Microsoft můžou používat speciální formát, který se neověří jako JWT a může být také zašifrovaný pro uživatele s uživatelským účtem (účtem 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.

Chybná 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 se obory neudělí, consent_required vrátí se 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 udělení není podporován v /common kontextu ověřování ani /consumers v kontextu ověřování. Místo toho použijte /organizations NEBO ID tenanta.

Další informace

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