Przepływy uwierzytelniania obsługiwane w usłudze MSAL

Biblioteka Microsoft Authentication Library (MSAL) obsługuje kilka dotacji autoryzacji i skojarzonych przepływów tokenów do użycia przez różne typy aplikacji i scenariusze.

Przepływ uwierzytelniania	Umożliwia	Obsługiwane typy aplikacji
Kod autoryzacji	Logowanie użytkownika i uzyskiwanie dostępu do internetowych interfejsów API w imieniu użytkownika.	* Aplikacje klasyczne * Rozwiązania mobilne * Aplikacja jednostronicowa (SPA) (wymaga PKCE) * Sieć Web
Poświadczenia klienta	Dostęp do internetowych interfejsów API przy użyciu tożsamości samej aplikacji. Zazwyczaj używane do komunikacji między serwerami i zautomatyzowanych skryptów, które nie wymagają interakcji z użytkownikiem.	Daemon
Kod urządzenia	Logowanie użytkownika i dostęp do internetowych interfejsów API w imieniu użytkownika na urządzeniach z ograniczonymi danymi wejściowymi, takich jak inteligentne telewizory i urządzenia internetu rzeczy (IoT). Używane również przez aplikacje interfejsu wiersza polecenia.	Desktop, Mobile
Niejawne udzielanie	Logowanie użytkownika i dostęp do internetowych interfejsów API w imieniu użytkownika. Niejawny przepływ udzielania nie jest już zalecany — zamiast tego użyj kodu autoryzacji z kluczem dowodowym dla programu Code Exchange (PKCE).	* Aplikacja jednostronicowa (SPA) * Sieć Web
On-behalf-of (OBO)	Dostęp z internetowego interfejsu API "nadrzędnego" do internetowego interfejsu API "podrzędnego" w imieniu użytkownika. Tożsamość użytkownika i uprawnienia delegowane są przekazywane do podrzędnego interfejsu API z nadrzędnego interfejsu API.	Internetowy interfejs API
Nazwa użytkownika/hasło (ROPC)	Umożliwia aplikacji logowanie użytkownika przez bezpośrednie obsługiwanie hasła. Przepływ ROPC NIE jest zalecany.	Desktop, Mobile
Zintegrowane uwierzytelnianie systemu Windows (IWA)	Umożliwia aplikacjom na komputerach przyłączonych do domeny lub microsoft Entra ID dyskretne uzyskanie tokenu (bez żadnej interakcji interfejsu użytkownika od użytkownika).	Desktop, Mobile

Tokeny

Aplikacja może używać co najmniej jednego przepływu uwierzytelniania. Każdy przepływ używa niektórych typów tokenów do uwierzytelniania, autoryzacji i odświeżania tokenu, a niektóre używają również kodu autoryzacji.

Przepływ lub akcja uwierzytelniania	Wymaga	Token identyfikatora	Token dostępu	Odświeżanie tokenu	Kod autoryzacji
Przepływ kodu autoryzacji		✅	✅	✅	✅
Poświadczenia klienta			✅ (tylko aplikacja)
Przepływ kodu urządzenia		✅	✅	✅
Niejawny przepływ		✅	✅
Przepływ „w imieniu”	Token dostępu	✅	✅	✅
Nazwa użytkownika/hasło (ROPC)	Nazwa użytkownika, hasło	✅	✅	✅
Przepływ hybrydowego identyfikatora OIDC		✅			✅
Odświeżanie realizacji tokenu	Odświeżanie tokenu	✅	✅	✅

Uwierzytelnianie interakcyjne i nieinterakcyjne

Kilka z tych przepływów obsługuje pozyskiwanie tokenów interakcyjnych i nieinterakcyjnych.

• Interakcyjne — użytkownik może zostać poproszony o podanie danych wejściowych przez serwer autoryzacji. Na przykład aby się zalogować, wykonać uwierzytelnianie wieloskładnikowe (MFA) lub udzielić zgody na więcej uprawnień dostępu do zasobów.
• Nieinterakcyjne — użytkownik może nie być monitowany o podanie danych wejściowych. Nazywana również pozyskiwaniem tokenu dyskretnego, aplikacja próbuje uzyskać token przy użyciu metody, w której serwer autoryzacji może nie monitować użytkownika o podanie danych wejściowych.

Aplikacja oparta na protokole MSAL powinna najpierw spróbować uzyskać token w trybie dyskretnym i wrócić do metody interaktywnej tylko wtedy, gdy próba nieinterakacyjna zakończy się niepowodzeniem. Aby uzyskać więcej informacji na temat tego wzorca, zobacz Uzyskiwanie i buforowanie tokenów przy użyciu biblioteki Microsoft Authentication Library (MSAL).

Kod autoryzacji

Udzielanie kodu autoryzacji OAuth 2.0 może być używane przez aplikacje internetowe, aplikacje jednostronicowe (SPA) i aplikacje natywne (mobilne i klasyczne) w celu uzyskania dostępu do chronionych zasobów, takich jak internetowe interfejsy API.

Gdy użytkownicy logują się do aplikacji internetowych, aplikacja otrzymuje kod autoryzacji, który może zrealizować dla tokenu dostępu w celu wywołania internetowych interfejsów API.

Na powyższym diagramie aplikacja:

1. Żąda kodu autoryzacji, który został zrealizowany dla tokenu dostępu.
2. Używa tokenu dostępu do wywoływania internetowego interfejsu API, takiego jak Microsoft Graph.

Ograniczenia dotyczące kodu autoryzacji

• Aplikacje jednostronicowe wymagają klucza dowodowego dla wymiany kodu (PKCE) podczas korzystania z przepływu udzielania kodu autoryzacji. Protokół PKCE jest obsługiwany przez bibliotekę MSAL.

• Specyfikacja protokołu OAuth 2.0 wymaga użycia kodu autoryzacji do realizacji tokenu dostępu tylko raz.

  Jeśli próbujesz uzyskać token dostępu wiele razy z tym samym kodem autoryzacji, zostanie zwrócony błąd podobny do poniższego przez Platforma tożsamości Microsoft. Należy pamiętać, że niektóre biblioteki i struktury żądają kodu autoryzacji automatycznie, a żądanie kodu ręcznie w takich przypadkach spowoduje również ten błąd.

  AADSTS70002: Error validating credentials. AADSTS54005: OAuth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token.

Poświadczenia klienta

Przepływ poświadczeń klienta protokołu OAuth 2 umożliwia dostęp do zasobów hostowanych w Internecie przy użyciu tożsamości aplikacji. Ten typ udzielania jest często używany w przypadku interakcji typu serwer-serwer (S2S), które muszą być uruchamiane w tle bez natychmiastowej interakcji z użytkownikiem. Tego typu aplikacje są często określane jako demony lub usługi.

Poświadczenia klienta udzielają przepływu umożliwiają usłudze internetowej (poufnemu klientowi) używanie własnych poświadczeń zamiast personifikacji użytkownika w celu uwierzytelnienia podczas wywoływania innej usługi internetowej. W tym scenariuszu klient jest zazwyczaj usługą internetową warstwy środkowej, usługą demona lub witryną internetową. W celu zapewnienia wyższego poziomu Platforma tożsamości Microsoft umożliwia również usłudze wywołującej użycie certyfikatu (zamiast wspólnego wpisu tajnego) jako poświadczenia.

Wpisy tajne aplikacji

Na powyższym diagramie aplikacja:

1. Uzyskuje token przy użyciu poświadczeń wpisu tajnego aplikacji lub hasła.
2. Używa tokenu do tworzenia żądań zasobów.

Certyfikaty

Na powyższym diagramie aplikacja:

1. Uzyskuje token przy użyciu poświadczeń certyfikatu.
2. Używa tokenu do tworzenia żądań zasobów.

Ten typ poświadczeń klienta musi być następujący:

• Zarejestrowane w usłudze Azure AD.
• Przekazany podczas konstruowania poufnego obiektu aplikacji klienckiej w kodzie.

Ograniczenia dotyczące poświadczeń klienta

Przepływ poufnego klienta nie jest obsługiwany na platformach mobilnych, takich jak Android, iOS lub platforma uniwersalna systemu Windows (UWP). Aplikacje mobilne są uznawane za publiczne aplikacje klienckie, które nie mogą zagwarantować poufności wpisów tajnych uwierzytelniania.

Kod urządzenia

Przepływ kodu urządzenia OAuth 2 umożliwia użytkownikom logowanie się do urządzeń z ograniczonymi danymi wejściowymi, takich jak inteligentne telewizory, urządzenia Internetu rzeczy (IoT) i drukarki. Uwierzytelnianie interakcyjne przy użyciu identyfikatora Entra firmy Microsoft wymaga przeglądarki internetowej. Jeśli urządzenie lub system operacyjny nie udostępnia przeglądarki internetowej, przepływ kodu urządzenia umożliwia interaktywne logowanie się przy użyciu innego urządzenia, takiego jak komputer lub telefon komórkowy.

Korzystając z przepływu kodu urządzenia, aplikacja uzyskuje tokeny za pośrednictwem dwuetapowego procesu przeznaczonego dla tych urządzeń i systemów operacyjnych.

Na powyższym diagramie:

1. Za każdym razem, gdy wymagane jest uwierzytelnianie użytkownika, aplikacja udostępnia kod i prosi użytkownika o użycie innego urządzenia, takiego jak smartfon połączony z Internetem, aby odwiedził adres URL (na przykład https://microsoft.com/devicelogin). Następnie użytkownik jest monitowany o wprowadzenie kodu i przechodzi przez normalne środowisko uwierzytelniania, w tym monity o wyrażenie zgody i uwierzytelnianie wieloskładnikowe, w razie potrzeby.
2. Po pomyślnym uwierzytelnieniu żądana aplikacja odbiera wymagane tokeny z Platforma tożsamości Microsoft i używa ich do wykonywania wymaganych wywołań internetowego interfejsu API.

Ograniczenia dotyczące kodu urządzenia

• Przepływ kodu urządzenia jest dostępny tylko dla publicznych aplikacji klienckich.
• Podczas inicjowania publicznej aplikacji klienckiej w biblioteki MSAL użyj jednego z następujących formatów urzędu:
  • Oparte na dzierżawie: https://login.microsoftonline.com/{tenant}/, gdzie {tenant} jest identyfikatorEM GUID reprezentującym identyfikator dzierżawy lub nazwą domeny skojarzona z dzierżawą.
  • Konta służbowe: https://login.microsoftonline.com/organizations/.

Niejawne udzielenie

Niejawne przyznanie zostało zastąpione przez przepływ kodu autoryzacji za pomocą PKCE jako preferowany i bardziej bezpieczny przepływ przyznawania tokenów dla aplikacji jednostronicowych po stronie klienta (SPA). Jeśli tworzysz SPA, zamiast tego użyj przepływu kodu autoryzacji z PKCE.

Jednostronicowe aplikacje internetowe napisane w języku JavaScript (w tym struktury, takie jak Angular, Vue.js lub React.js) są pobierane z serwera, a ich kod działa bezpośrednio w przeglądarce. Ponieważ ich kod po stronie klienta jest uruchamiany w przeglądarce, a nie na serwerze internetowym, mają różne właściwości zabezpieczeń niż tradycyjne aplikacje internetowe po stronie serwera. Przed udostępnieniem klucza dowodowego dla wymiany kodu (PKCE) dla przepływu kodu autoryzacji niejawny przepływ udzielania był używany przez dostawcy usług w celu zwiększenia czasu odpowiedzi i wydajności uzyskiwania tokenów dostępu.

Przepływ niejawnego udzielania OAuth 2 umożliwia aplikacji uzyskiwanie tokenów dostępu z Platforma tożsamości Microsoft bez przeprowadzania wymiany poświadczeń serwera zaplecza. Niejawny przepływ udzielania umożliwia aplikacji logowanie użytkownika, utrzymywanie sesji i uzyskiwanie tokenów dla innych internetowych interfejsów API z poziomu kodu JavaScript pobranego i uruchamianego przez agenta użytkownika (zazwyczaj przeglądarki internetowej).

Ograniczenia dotyczące niejawnego udzielania

Niejawny przepływ udzielania nie obejmuje scenariuszy aplikacji korzystających z międzyplatformowych struktur Języka JavaScript, takich jak Electron lub React Native. Platformy międzyplatformowe, takie jak te, wymagają dodatkowych możliwości interakcji z natywnymi platformami komputerowymi i mobilnymi, na których działają.

Tokeny wystawione za pośrednictwem niejawnego trybu przepływu mają ograniczenie długości, ponieważ są zwracane do przeglądarki w adresie URL (gdzie response_mode to query lub fragment). Niektóre przeglądarki ograniczają długość adresu URL na pasku przeglądarki i kończą się niepowodzeniem, gdy jest za długa. W związku z tym te niejawne tokeny przepływu nie zawierają groups ani wids oświadczeń.

On-behalf-of (OBO)

Przepływ przepływu uwierzytelniania OAuth 2 w imieniu jest używany, gdy aplikacja wywołuje usługę lub internetowy interfejs API, który z kolei musi wywoływać inną usługę lub internetowy interfejs API przy użyciu delegowanej tożsamości użytkownika i uprawnień, które muszą być propagowane za pośrednictwem łańcucha żądań. Aby usługa warstwy środkowej wysyłała uwierzytelnione żądania do usługi podrzędnej, musi zabezpieczyć token dostępu z Platforma tożsamości Microsoft w imieniu żądanego użytkownika.

Na powyższym diagramie:

1. Aplikacja uzyskuje token dostępu dla internetowego interfejsu API.
2. Klient (aplikacja internetowa, klasyczna, mobilna lub jednostronicowa) wywołuje chroniony internetowy interfejs API, dodając token dostępu jako token elementu nośnego w nagłówku uwierzytelniania żądania HTTP. Internetowy interfejs API uwierzytelnia użytkownika.
3. Gdy klient wywołuje internetowy interfejs API, internetowy interfejs API żąda innego tokenu w imieniu użytkownika.
4. Chroniony internetowy interfejs API używa tego tokenu do wywoływania podrzędnego internetowego interfejsu API w imieniu użytkownika. Internetowy interfejs API może również później żądać tokenów dla innych podrzędnych interfejsów API (ale nadal w imieniu tego samego użytkownika).

Nazwa użytkownika/hasło (ROPC)

Ostrzeżenie

Przepływ poświadczeń hasła właściciela zasobu (ROPC) nie jest już zalecany. RopC wymaga wysokiego stopnia zaufania i ujawnienia poświadczeń. Używaj ropy ROPC tylko wtedy, gdy nie można użyć bezpieczniejszego przepływu. Aby uzyskać więcej informacji, zobacz Co to jest rozwiązanie rosnącego problemu haseł?.

Przyznawanie poświadczeń hasła właściciela zasobu OAuth 2 (ROPC) umożliwia aplikacji logowanie użytkownika bezpośrednio przez obsługę hasła. W aplikacji klasycznej możesz użyć przepływu nazwy użytkownika/hasła, aby uzyskać token w trybie dyskretnym. W przypadku korzystania z aplikacji nie jest wymagany żaden interfejs użytkownika.

Niektóre scenariusze aplikacji, takie jak DevOps, mogą znaleźć przydatne ropc, ale należy unikać go w dowolnej aplikacji, w której udostępniasz interaktywny interfejs użytkownika na potrzeby logowania użytkownika.

Na powyższym diagramie aplikacja:

1. Uzyskuje token, wysyłając nazwę użytkownika i hasło do dostawcy tożsamości.
2. Wywołuje internetowy interfejs API przy użyciu tokenu.

Aby uzyskać token dyskretnie na komputerach przyłączonych do domeny systemu Windows, zalecamy użycie Menedżera kont sieci Web (WAM) zamiast ROPC. W innych scenariuszach użyj przepływu kodu urządzenia.

Ograniczenia dla ropc

Następujące ograniczenia dotyczą aplikacji przy użyciu przepływu ROPC:

• Logowanie jednokrotne nie jest obsługiwane.
• Uwierzytelnianie wieloskładnikowe (MFA) nie jest obsługiwane.
  • Przed rozpoczęciem korzystania z tego przepływu zapoznaj się z administratorem dzierżawy — uwierzytelnianie wieloskładnikowe jest często używaną funkcją.
• Dostęp warunkowy jest nieobsługiwany.
• RopC działa tylko w przypadku kont służbowych.
• Osobiste konta Microsoft (MSA) nie są obsługiwane przez ROPC.
• RopC jest obsługiwany w aplikacjach klasycznych i .NET .NET.
• RopC nie jest obsługiwany w aplikacjach platformy platforma uniwersalna systemu Windows (UWP).
• RopC w Tożsamość zewnętrzna Microsoft Entra jest obsługiwany tylko dla kont lokalnych.
  • Aby uzyskać informacje o ropc w MSAL.NET i Tożsamość zewnętrzna Microsoft Entra, zobacz Poświadczenia hasła właściciela zasobu (ROPC) z B2C.

Zintegrowane uwierzytelnianie systemu Windows (IWA)

Uwaga

Zintegrowane uwierzytelnianie systemu Windows zostało zastąpione bardziej niezawodnym sposobem dyskretnego pobierania tokenów — WAM. WAM może zalogować się w trybie dyskretnym bieżącego użytkownika systemu Windows. Ten przepływ pracy nie wymaga złożonej konfiguracji, a nawet działa w przypadku kont osobistych (Microsoft). Wewnętrznie broker systemu Windows (WAM) spróbuje kilka strategii, aby uzyskać token dla bieżącego użytkownika systemu Windows, w tym IWA i zrealizować prT. Eliminuje to większość ograniczeń dotyczących IWA.

Biblioteka MSAL obsługuje zintegrowane uwierzytelnianie systemu Windows (IWA) dla aplikacji klasycznych i mobilnych uruchamianych na komputerach z systemem Windows przyłączonych do domeny lub komputerach z systemem Windows dołączonych do usługi Microsoft Entra ID. Korzystając z IWA, te aplikacje uzyskują token dyskretnie bez konieczności interakcji interfejsu użytkownika przez użytkownika.

Na powyższym diagramie aplikacja:

1. Uzyskuje token przy użyciu zintegrowanego uwierzytelniania systemu Windows.
2. Używa tokenu do tworzenia żądań zasobów.

Ograniczenia dla IWA

• Zgodność. Zintegrowane uwierzytelnianie systemu Windows (IWA) jest włączone dla aplikacji klasycznych platformy .NET, .NET i platforma uniwersalna systemu Windows (UWP). Aplikacja IWA obsługuje tylko użytkowników federacyjnych usług ADFS — użytkowników utworzonych w usłudze Active Directory i wspieranych przez identyfikator Firmy Microsoft Entra. Użytkownicy utworzony bezpośrednio w usłudze Microsoft Entra ID bez tworzenia kopii zapasowych usługi Active Directory (zarządzanych użytkowników) nie mogą używać tego przepływu uwierzytelniania.
• Uwierzytelnianie wieloskładnikowe (MFA) Uwierzytelnianie nieinterakcyjne (dyskretne) IWA może zakończyć się niepowodzeniem, jeśli usługa MFA jest włączona w dzierżawie identyfikatora Entra firmy Microsoft, a wyzwanie uwierzytelniania wieloskładnikowego jest wystawiane przez identyfikator firmy Microsoft Entra. W przypadku niepowodzenia interfejsu IWA należy wrócić do interaktywnej metody uwierzytelniania zgodnie z wcześniejszym opisem. Identyfikator entra firmy Microsoft używa sztucznej inteligencji do określenia, kiedy wymagane jest uwierzytelnianie dwuskładnikowe. Uwierzytelnianie dwuskładnikowe jest zwykle wymagane, gdy użytkownik loguje się z innego kraju/regionu, gdy jest połączony z siecią firmową bez korzystania z sieci VPN, a czasami gdy jest połączony za pośrednictwem sieci VPN. Ponieważ konfiguracja i częstotliwość wyzwań uwierzytelniania wieloskładnikowego mogą znajdować się poza kontrolą dewelopera, aplikacja powinna bezpiecznie obsługiwać niepowodzenie pozyskiwania tokenu dyskretnego IWA.
• Ograniczenia identyfikatora URI urzędu. Urząd przekazany podczas konstruowania publicznej aplikacji klienckiej musi być jednym z następujących elementów:
  • https://login.microsoftonline.com/{tenant}/ — Ten urząd wskazuje aplikację z jedną dzierżawą, której odbiorcy logowania są ograniczeni do użytkowników w określonej dzierżawie microsoft Entra ID. Wartość {tenant} może być identyfikatorem dzierżawy w formularzu GUID lub nazwą domeny skojarzona z dzierżawą.
  • https://login.microsoftonline.com/organizations/ — Ten urząd wskazuje aplikację wielodostępną, której odbiorcy logowania są użytkownikami w dowolnej dzierżawie identyfikatora Entra firmy Microsoft.
• Konta osobiste. Wartości urzędu nie mogą zawierać /common ani /consumers dlatego, że osobiste konta Microsoft (MSA) nie są obsługiwane przez IWA.
• Wymagania dotyczące zgody. Ponieważ usługa IWA jest przepływem dyskretnym, użytkownik aplikacji musi wcześniej wyrazić zgodę na korzystanie z aplikacji lub administrator dzierżawy musi wcześniej wyrazić zgodę na wszystkich użytkowników w dzierżawie w celu korzystania z aplikacji. Aby spełnić oba wymagania, należy wykonać jedną z tych operacji:
  • Jako deweloper aplikacji wybrano dla siebie pozycję Udziel w witrynie Azure Portal.
  • Administrator dzierżawy wybrał pozycję Udziel/odwołaj zgodę administratora dla {domeny dzierżawy} na karcie Uprawnienia interfejsu API rejestracji aplikacji w witrynie Azure Portal. Zobacz Dodawanie uprawnień dostępu do internetowego interfejsu API.
  • Udostępniono użytkownikom sposób wyrażania zgody na aplikację; Zobacz Omówienie uprawnień i zgody w Platforma tożsamości Microsoft.
  • Użyliśmy sposobu, w jaki administrator dzierżawy wyrazi zgodę na aplikację; Zobacz Omówienie uprawnień i zgody w Platforma tożsamości Microsoft.

Następne kroki

Po przejrzeniu przepływów uwierzytelniania obsługiwanych przez bibliotekę MSAL dowiedz się więcej na temat uzyskiwania i buforowania tokenów używanych w tych przepływach.