Microsoft Identitásplatform és OAuth 2.0 erőforrás-tulajdonosi jelszó hitelesítő adatai

  • Cikk

A Microsoft Identitásplatform támogatja az OAuth 2.0 erőforrás-tulajdonosi jelszó hitelesítő adatainak (ROPC) megadását, amely lehetővé teszi, hogy az alkalmazás közvetlenül a jelszavával jelentkezzen be a felhasználóba. Ez a cikk azt ismerteti, hogy hogyan programozhat közvetlenül a protokollra építve az alkalmazásban. Azt javasoljuk, hogy amikor lehetséges, inkább a támogatott Microsoft hitelesítési kódtárakat (MSAL) használja a tokenek beszerzéséhez és biztonságos webes API-k meghívásához. Tekintse meg az MSAL-t használó mintaalkalmazásokat is.

Figyelmeztetés

A Microsoft azt javasolja, hogy ne használja a ROPC-folyamatot. A legtöbb forgatókönyvben biztonságosabb alternatívák érhetők el és ajánlottak. Ez a folyamat nagyon nagy fokú bizalmat igényel az alkalmazásban, és olyan kockázatokat hordoz, amelyek más folyamatokban nincsenek jelen. Ezt a folyamatot csak akkor érdemes használni, ha más biztonságosabb folyamatok nem életképesek.

Fontos

  • A Microsoft Identitásplatform csak a Microsoft Entra-bérlőkben lévő ROPC-támogatást támogatja, a személyes fiókokat nem. Ez azt jelenti, hogy bérlőspecifikus végpontot (https://login.microsoftonline.com/{TenantId_or_Name}) vagy végpontot kell használnia organizations .
  • A Microsoft Entra-bérlőre meghívott személyes fiókok nem használhatják a ROPC-folyamatot.
  • A jelszóval nem rendelkező fiókok nem tudnak bejelentkezni a ROPC-val, ami azt jelenti, hogy az olyan funkciók, mint az SMS-bejelentkezés, a FIDO és az Authenticator alkalmazás nem fognak működni ezzel a folyamattal. Ha az alkalmazás vagy a felhasználók igénylik ezeket a funkciókat, a ROPC-n kívül más támogatási típust használjon.
  • Ha a felhasználóknak többtényezős hitelesítést (MFA) kell használniuk az alkalmazásba történő bejelentkezéshez, az letiltást fog eredményezni.
  • A ROPC nem támogatott hibrid identitás-összevonási forgatókönyvekben (például a helyszíni fiókok hitelesítéséhez használt Microsoft Entra ID és AD FS). Ha a felhasználókat teljes oldalról átirányítják egy helyi azonosítószolgáltatóhoz, a Microsoft Entra ID nem tudja tesztelni a felhasználónevet és a jelszót az adott azonosítószolgáltatóval szemben. Az ROPC azonban támogatja az átmenő hitelesítést.
  • A hibrid identitás-összevonási forgatókönyv kivétele a következő: Az AllowCloudPasswordValidation értékre beállított Home Realm Discovery szabályzat lehetővé teszi, hogy a ROPC-folyamat működjön az összevont felhasználók számára, amikor egy helyszíni jelszót szinkronizál a felhőbe. További információk: Összevont felhasználók közvetlen ROPC-hitelesítésének engedélyezése örökölt alkalmazások esetén.
  • A kezdő vagy záró szóközöket tartalmazó jelszavakat a ROPC-folyamat nem támogatja.

Protokolldiagram

Az alábbi ábrán a ROPC-folyamat látható.

Diagram showing the resource owner password credential flow

Engedélyezési kérelem

A ROPC-folyamat egyetlen kérelem; elküldi az ügyfélazonosítást és a felhasználó hitelesítő adatait az identitásszolgáltatónak, és cserébe jogkivonatokat kap. Ehhez az ügyfélnek meg kell kérnie a felhasználó e-mail-címét (UPN) és jelszavát. Közvetlenül a sikeres kérés után az ügyfélnek biztonságosan el kell távolítania a felhasználó hitelesítő adatait a memóriából. Soha nem mentheti meg őket.

// 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
Paraméter Feltétel Leírás
tenant Kötelező A címtár-bérlő, amelybe a felhasználót be szeretné jelentkeztetni. A bérlő lehet GUID vagy rövid névformátumban. A paramétere azonban nem állítható be common vagy consumers, de lehet, hogy a következőre organizationsvan állítva.
client_id Kötelező Az alkalmazás (ügyfél) azonosítója, amelyet a Microsoft Entra Felügyeleti központ Alkalmazásregisztrációk az alkalmazáshoz rendelt oldal.
grant_type Kötelező A beállításnak a passwordkövetkezőnek kell lennie: .
username Kötelező A felhasználó e-mail címe.
password Kötelező A felhasználó jelszava.
scope Ajánlott Az alkalmazás által igényelt hatókörök vagy engedélyek szóközzel elválasztott listája. Az interaktív folyamatokban a rendszergazdának vagy a felhasználónak előre hozzá kell adnia ezeket a hatóköröket.
client_secret Néha szükséges Ha az alkalmazás nyilvános ügyfél, akkor az client_secretclient_assertion alkalmazás nem vehető fel. Ha az alkalmazás bizalmas ügyfél, akkor azt is tartalmaznia kell.
client_assertion Néha szükséges A tanúsítvány használatával létrehozott másik formátum client_secret. További információkért tekintse meg a tanúsítvány hitelesítő adatait.

Sikeres hitelesítési válasz

Az alábbi példa egy sikeres jogkivonat-választ mutat be:

{
    "token_type": "Bearer",
    "scope": "User.Read profile openid email",
    "expires_in": 3599,
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD..."
}
Paraméter Formátum Leírás
token_type Sztring Mindig a következőre van Bearerállítva: .
scope Szóközzel elválasztott sztringek Ha egy hozzáférési jogkivonatot ad vissza, ez a paraméter felsorolja azokat a hatóköröket, amelyekhez a hozzáférési jogkivonat érvényes.
expires_in egész A belefoglalt hozzáférési jogkivonat érvényességi ideje másodpercben.
access_token Átlátszatlan sztring A kért hatókörökhöz lett kiadva.
id_token JWT Ki van adva, ha az eredeti scope paraméter tartalmazza a hatókört openid .
refresh_token Átlátszatlan sztring Ki van adva, ha az eredeti scope paramétert tartalmazza offline_access.

A frissítési jogkivonattal új hozzáférési jogkivonatokat és jogkivonatokat szerezhet be az OAuth Code-folyamat dokumentációjában ismertetett folyamattal.

Figyelmeztetés

Ne kísérelje meg a jogkivonatok érvényesítését vagy olvasását a kódban a nem birtokolt API-k esetében, beleértve az ebben a példában szereplő jogkivonatokat is. A Microsoft-szolgáltatások jogkivonatai olyan speciális formátumot használhatnak, amely nem érvényesíthető JWT-ként, és titkosíthatók a fogyasztói (Microsoft-fiók) felhasználók számára is. Bár a jogkivonatok olvasása hasznos hibakeresési és tanulási eszköz, ne vegyen fel függőségeket a kódban, és ne feltételezze a nem ön által vezérelt API-khoz tartozó jogkivonatokat.

Hibaválasz

Ha a felhasználó nem adta meg a megfelelő felhasználónevet vagy jelszót, vagy az ügyfél nem kapta meg a kért hozzájárulást, a hitelesítés sikertelen lesz.

Hiba Leírás Ügyfélművelet
invalid_grant A hitelesítés nem sikerült A hitelesítő adatok helytelenek voltak, vagy az ügyfél nem járult hozzá a kért hatókörökhöz. Ha a hatókörök nincsenek megadva, a consent_required rendszer hibát ad vissza. A hiba megoldásához az ügyfélnek webnézet vagy böngésző használatával kell elküldenie a felhasználót egy interaktív kérdésre.
invalid_request A kérés nem megfelelően lett létrehozva A támogatás típusa nem támogatott a vagy /consumers a /common hitelesítési környezetekben. Használja /organizations inkább a bérlőazonosítót.

További információ

A ROPC-folyamat példaalkalmazását a GitHubon található .NET-konzolalkalmazás kódmintájában tekintheti meg.