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

Artykuł
04/08/2024

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_secret`klasy 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_access`wartość .

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.

Udostępnij za pośrednictwem