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

Biblioteka Microsoft Authentication Library (MSAL) obsługuje kilka uprawnień autoryzacji i skojarzonych mechanizmów przepływu tokenów do używania przez różne typy aplikacji i w różnych scenariuszach.

Tokens

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.

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 wymienić na token dostępu, aby wywołać interfejsy API.

Na powyższym diagramie aplikacja:

1. Żąda kodu autoryzacji, który można wymienić na token 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 spróbujesz uzyskać token dostępu wiele razy z tym samym kodem autoryzacji, zostanie zwrócony błąd podobny do poniższego przez platformę tożsamości firmy 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.

Dane uwierzytelniające 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.

Przepływ autoryzacji przy użyciu poświadczeń klienta pozwala usłudze internetowej (poufny klient) na używanie własnych poświadczeń zamiast podszywania się pod 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 bezpieczeństwa platforma tożsamości Microsoft umożliwia również usłudze wywołującej użycie certyfikatu (zamiast wspólnego sekretu) jako poświadczenia.

Sekrety aplikacji

Na powyższym diagramie aplikacja:

1. Uzyskuje token za pomocą tajemnicy aplikacji lub poświadczeń hasła.
2. Używa tokenu do tworzenia żądań zasobów.

Certificates

Na powyższym diagramie aplikacja:

1. Pobiera token przy użyciu certyfikatowych poświadczeń.
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.
• Przekazywany podczas tworzenia obiektu aplikacji wrażliwego klienta 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 poproszony o wprowadzenie kodu i przechodzi przez normalny proces uwierzytelniania, w tym prośby o wyrażenie zgody oraz uwierzytelnianie wieloczynnikowe, w razie potrzeby.
2. Po pomyślnym uwierzytelnieniu żądana aplikacja odbiera wymagane tokeny z platformy tożsamości firmy 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 bibliotece MSAL użyj jednego z następujących formatów autoryzacji:
  • Oparte na dzierżawie: https://login.microsoftonline.com/{tenant}/, gdzie {tenant} jest identyfikatorem GUID reprezentującym identyfikator dzierżawy lub nazwą domeny skojarzoną z dzierżawą.
  • Konta służbowe i szkolne: 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.

Niejawny przepływ udzielania OAuth 2 umożliwia aplikacji uzyskiwanie tokenów dostępu z platformy tożsamości firmy Microsoft bez przeprowadzania wymiany poświadczeń serwera zapleczowego. 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 ukryte tokeny przepływu nie zawierają groups ani wids żądań.

W imieniu (OBO)

Przepływ uwierzytelniania OAuth 2 w imieniu użytkownika jest używany, gdy aplikacja wywołuje usługę lub API internetowe, które z kolei musi wywoływać inną usługę lub API internetowe 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 platformy 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, desktopowa, mobilna lub jednostronicowa) wywołuje chroniony interfejs API, dodając token dostępu jako token nosiciela 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 webowy interfejs API używa tego tokenu do wywoływania podrzędnego webowego 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)

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 zastosowania aplikacji, takie jak DevOps, mogą uznać ROPC za przydatne, ale należy unikać go w dowolnej aplikacji, w której udostępniasz interaktywny interfejs użytkownika do logowania użytkowników.

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 dla 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.
  • Zanim zaczniesz korzystać z tego przepływu, skonsultuj się z administratorem dzierżawcy — uwierzytelnianie wieloskładnikowe jest często używaną funkcją.
• Dostęp warunkowy jest nieobsługiwany.
• ROPC działa tylko dla kont służbowych lub szkolnych.
• Osobiste konta Microsoft (MSA) nie są obsługiwane przez ROPC.
• ROPC jest obsługiwany w aplikacjach desktopowych i .NET.
• ROPC nie jest obsługiwany w aplikacjach Platformy uniwersalnej systemu Windows (UWP).
• ROPC w Tożsamość zewnętrzna Microsoft Entra jest obsługiwane tylko dla kont lokalnych.
  • Aby uzyskać informacje o ropc w MSAL.NET i identyfikatorze zewnętrznym firmy Microsoft Entra, zobacz Poświadczenia hasła właściciela zasobu (ROPC) z B2C.

Zintegrowane uwierzytelnianie systemu Windows (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 w sposób niewidoczny, bez konieczności interakcji użytkownika z interfejsem.

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 Windows (IWA) jest włączone dla aplikacji desktopowych .NET, .NET i platformy uniwersalnej 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 utworzeni bezpośrednio w usłudze Microsoft Entra ID, bez zaplecza Active Directory (zarządzani użytkownicy), 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 uwierzytelniania wieloskładnikowego (MFA) jest włączona w dzierżawie Microsoft Entra ID, a wyzwanie MFA jest wystawiane przez Microsoft Entra ID. 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 płynnie obsługiwać niepowodzenie pozyskiwania dyskretnego tokenu IWA.
• Ograniczenia identyfikatora URI autorytetu. Urząd przekazany podczas tworzenia publicznej aplikacji klienckiej musi być jednym z następujących:
  • https://login.microsoftonline.com/{tenant}/ — Ten autorytet wskazuje aplikację jednokrotnego dzierżawcy, 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 autorytet wskazuje aplikację wielodostępną, której odbiorcami logowania są użytkownicy w dowolnej dzierżawie Microsoft Entra ID.
• Konta osobiste. Wartości autorytetu nie mogą zawierać/common ani /consumers, ponieważ osobiste konta Microsoft (MSA) nie są obsługiwane przez IWA.
• Wymagania dotyczące zgody. Ponieważ usługa IWA jest procesem dyskretnym, użytkownik aplikacji musi wcześniej wyrazić zgodę na jej używanie lub administrator dzierżawy musi wcześniej udzielić zgody wszystkim użytkownikom w dzierżawie na korzystanie z aplikacji. Aby spełnić oba wymagania, należy wykonać jedną z tych operacji:
  • Jako deweloper aplikacji samodzielnie wybrałeś opcję Udziel w portalu Azure.
  • 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 na platformie tożsamości firmy Microsoft.
  • Udostępniłeś sposób, aby administrator dzierżawy mógł wyrazić zgodę na aplikację; zobacz Omówienie uprawnień i zgody na platformie tożsamości firmy 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.