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

Článek
04/08/2024

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 `password`hodnotu .
`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_secret`pomocí 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 `Bearer`hodnotu .
`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_access`pů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.

Sdílet prostřednictvím