Platforma tożsamości Microsoft i poświadczenia hasła właściciela zasobu OAuth 2.0

  • Artykuł

Program Platforma tożsamości Microsoft obsługuje przyznanie poświadczeń hasła właściciela zasobu (ROPC) właściciela zasobu OAuth 2.0, co umożliwia aplikacji logowanie użytkownika bezpośrednio przy użyciu obsługi hasła. W tym artykule opisano, jak programować aplikację bezpośrednio w oparciu o protokół. Jeśli to możliwe, zalecamy używanie obsługiwanych bibliotek Microsoft Authentication Libraries (MSAL) zamiast uzyskiwania tokenów i wywoływania zabezpieczonych internetowych interfejsów API. Przyjrzyj się również przykładowym aplikacjom korzystającym z biblioteki MSAL.

Ostrzeżenie

Firma Microsoft zaleca, aby nie używać przepływu ROPC. W większości scenariuszy dostępne są bezpieczniejsze alternatywy i zalecane. Ten przepływ wymaga bardzo wysokiego poziomu zaufania w aplikacji i niesie ze sobą ryzyko, które nie występują w innych przepływach. Tego przepływu należy używać tylko wtedy, gdy inne bezpieczniejsze przepływy nie są opłacalne.

Ważne

  • Platforma tożsamości Microsoft obsługuje tylko udzielanie ROPC w ramach dzierżaw firmy Microsoft, a nie kont osobistych. Oznacza to, że należy użyć punktu końcowego specyficznego dla dzierżawy (https://login.microsoftonline.com/{TenantId_or_Name}) lub punktu końcowego organizations .
  • Konta osobiste zaproszone do dzierżawy firmy Microsoft Entra nie mogą używać przepływu ROPC.
  • Konta, które nie mają haseł, nie mogą zalogować się przy użyciu rozwiązania ROPC, co oznacza, że funkcje takie jak logowanie sms, fiDO i aplikacja Authenticator nie będą działać z tym przepływem. Jeśli aplikacja lub użytkownicy wymagają tych funkcji, użyj typu przyznawania innego niż ROPC.
  • Użytkownicy zostaną zablokowani, jeśli będą musieli logować się w aplikacji przy użyciu uwierzytelniania wieloskładnikowego (MFA).
  • RopC nie jest obsługiwany w scenariuszach federacji tożsamości hybrydowej (na przykład Microsoft Entra ID i AD FS używanych do uwierzytelniania kont lokalnych). Jeśli użytkownicy są przekierowywani do lokalnych dostawców tożsamości, usługa Microsoft Entra nie może przetestować nazwy użytkownika ani hasła względem tego dostawcy tożsamości. Natomiast przepływ ROPC obsługuje uwierzytelnianie z przekazywaniem.
  • Wyjątek od scenariusza federacji tożsamości hybrydowej będzie następujący: Zasady odnajdywania obszaru głównego z ustawieniem AllowCloudPasswordValidation ustawioną na wartość TRUE umożliwią działanie przepływu ROPC dla użytkowników federacyjnych po zsynchronizowaniu hasła lokalnego z chmurą. Aby uzyskać więcej informacji, zobacz temat Włączanie bezpośredniego uwierzytelniania ROPC użytkowników federacyjnych w przypadku starszych aplikacji.
  • Hasła z wiodącymi lub końcowymi odstępami nie są obsługiwane przez przepływ ROPC.

Diagram protokołu

Na poniższym diagramie przedstawiono przepływ ROPC.

Diagram showing the resource owner password credential flow

Żądanie autoryzacji

Przepływ ROPC jest pojedynczym żądaniem; wysyła identyfikację klienta i poświadczenia użytkownika do dostawcy tożsamości i otrzymuje tokeny w zamian. Przed wykonaniem tej czynności klient musi zażądać adresu e-mail użytkownika (UPN) i hasła. Natychmiast po pomyślnym żądaniu klient powinien bezpiecznie odrzucić poświadczenia użytkownika z pamięci. Nigdy nie może ich uratować.

// 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 Warunek opis
tenant Wymagania Dzierżawa katalogu, do której chcesz zalogować użytkownika. Dzierżawa może być w formacie GUID lub przyjaznej nazwy. Jednak nie można ustawić parametru na common lub consumers, ale może być ustawiony na organizations.
client_id Wymagania Identyfikator aplikacji (klienta), który jest przypisany do aplikacji przez centrum administracyjne firmy Microsoft — Rejestracje aplikacji.
grant_type Wymagania Musi być ustawiona wartość password.
username Wymagania Adres e-mail użytkownika.
password Wymagania Hasło użytkownika.
scope Zalecane Rozdzielona spacjami lista zakresów lub uprawnień wymagana przez aplikację. W przepływie interaktywnym administrator lub użytkownik musi z wyprzedzeniem wyrazić zgodę na te zakresy.
client_secret Czasami wymagane Jeśli aplikacja jest klientem publicznym, nie można dołączyć elementu client_secret lub client_assertion . Jeśli aplikacja jest poufnym klientem, musi zostać uwzględniona.
client_assertion Czasami wymagane Inna forma client_secretklasy wygenerowana przy użyciu certyfikatu. Aby uzyskać więcej informacji, zobacz poświadczenia certyfikatu.

Pomyślna odpowiedź uwierzytelniania

W poniższym przykładzie przedstawiono pomyślną odpowiedź tokenu:

{
    "token_type": "Bearer",
    "scope": "User.Read profile openid email",
    "expires_in": 3599,
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD..."
}
Parametr Format opis
token_type String Zawsze ustaw wartość Bearer.
scope Oddzielone spacjami ciągi Jeśli zwrócono token dostępu, ten parametr zawiera listę zakresów, dla których token dostępu jest prawidłowy.
expires_in int Liczba sekund ważności dołączonego tokenu dostępu.
access_token Nieprzezroczystym ciągiem Wystawiono dla żądanych zakresów .
id_token JWT Wystawiono, jeśli oryginalny scope parametr zawierał openid zakres.
refresh_token Nieprzezroczystym ciągiem Wystawiono, jeśli oryginalny scope parametr zawiera offline_accesswartość .

Token odświeżania umożliwia uzyskanie nowych tokenów dostępu i tokenów odświeżania przy użyciu tego samego przepływu opisanego w dokumentacji przepływu kodu OAuth.

Ostrzeżenie

Nie próbuj weryfikować ani odczytywać tokenów dla żadnego interfejsu API, którego nie jesteś właścicielem, w tym tokenów w tym przykładzie, w kodzie. Tokeny dla usługi firmy Microsoft mogą używać specjalnego formatu, który nie będzie weryfikowany jako JWT, a także może być szyfrowany dla użytkowników klienta (konta Microsoft). Podczas odczytywania tokenów jest przydatnym narzędziem do debugowania i uczenia, nie należy brać zależności od tego w kodzie ani zakładać konkretnych informacji o tokenach, które nie są przeznaczone dla kontrolującego interfejsu API.

Odpowiedź błędna

Jeśli użytkownik nie podał poprawnej nazwy użytkownika lub hasła lub klient nie otrzymał żądanej zgody, uwierzytelnianie zakończy się niepowodzeniem.

Błąd opis Akcja klienta
invalid_grant Uwierzytelnianie nie powiodło się Poświadczenia były nieprawidłowe lub klient nie ma zgody na żądane zakresy. Jeśli zakresy nie zostaną przyznane, consent_required zostanie zwrócony błąd. Aby rozwiązać ten błąd, klient powinien wysłać użytkownika do interakcyjnego monitu przy użyciu widoku internetowego lub przeglądarki.
invalid_request Żądanie zostało nieprawidłowo skonstruowane Typ udzielenia nie jest obsługiwany w /common kontekstach uwierzytelniania lub /consumers . Zamiast tego użyj /organizations identyfikatora dzierżawy lub.

Dowiedz się więcej

Przykładowa implementacja przepływu ROPC można znaleźć w przykładzie kodu aplikacji konsolowej platformy .NET w witrynie GitHub.