Uwierzytelnianie aplikacji i użytkowników przy użyciu identyfikatora Entra firmy Microsoft

Podstawową funkcją Microsoft Entra ID dla aplikacji jest uwierzytelnianie, czyli proces, w którym użytkownicy potwierdzają swoją tożsamość, podając identyfikator osobisty, taki jak nazwa użytkownika lub adres e-mail. Podano dowód tożsamości. Dowód może być hasłem, artefaktem uwierzytelniania wieloskładnikowego, biometryczną lub bez hasła zgodą.

W tym artykule opisano, jak aplikacje używają identyfikatora Entra firmy Microsoft do uwierzytelniania użytkowników i aplikacji. Jest to trzeci z serii artykułów na temat tego, jak niezależni deweloperzy oprogramowania (ISV) mogą tworzyć i optymalizować swoje aplikacje dla identyfikatora Entra firmy Microsoft. W tej serii możesz dowiedzieć się więcej o następujących tematach:

Żądanie tokenów

Aplikacje żądają tokenu z identyfikatora Entra firmy Microsoft. Po otrzymaniu tokenu przez aplikacje mogą użyć informacji w tym tokenie, aby zidentyfikować użytkownika. Podczas tworzenia identyfikatora Entra firmy Microsoft użytkownicy mogą uwierzytelniać wiele aplikacji przy użyciu jednego zarejestrowanego konta Microsoft Entra ID (SSO). Metoda uwierzytelniania jednokrotnego umożliwia użytkownikom logowanie się do wielu niezależnych systemów oprogramowania przy użyciu jednego zestawu poświadczeń.

Protokoły, których deweloperzy mogą używać do żądania tokenu z identyfikatora Entra firmy Microsoft, używają przeglądarki do łączenia użytkownika z witryną internetową Microsoft Entra ID. Ta witryna internetowa umożliwia użytkownikowi prywatną konwersację z identyfikatorem Entra firmy Microsoft. Aplikacja nie jest uczestnikiem tej prywatnej konwersacji. Aplikacje uruchamiają witrynę internetową Microsoft Entra ID, w której użytkownik inicjuje proces uwierzytelniania. Po zakończeniu procesu uwierzytelniania identyfikator Entra firmy Microsoft przekierowuje użytkownika z powrotem do aplikacji z tokenem lub bez tego tokenu.

Ważne jest, aby użytkownicy rzadko musieli przejść przez proces uwierzytelniania. Im częściej użytkownicy muszą to zrobić, tym bardziej stają się podatni na zagrożenia, takie jak ataki phishingowe.

Zmniejszanie monitów logowania

Logowanie jednokrotne może zmniejszyć lub wyeliminować żądania logowania. Deweloperzy odgrywają istotną rolę w zmniejszaniu i eliminowaniu monitów logowania. Wszystkie aplikacje muszą udostępniać przeglądarkę, która uzyskuje dostęp do witryny internetowej Microsoft Entra ID, w której użytkownicy wykonują proces uwierzytelniania. Jeśli Aplikacja jest aplikacją jednostronicową (SPA) opartą na przeglądarce lub aplikacją internetową, nie jest wymagana żadna procedura dewelopera. Wszystkie aplikacje działające w przeglądarce korzystają z jej zasobów. W przypadku aplikacji natywnych uruchamianych na komputerach stacjonarnych i urządzeniach przenośnych deweloperzy muszą aktywnie zmniejszyć lub wyeliminować monity logowania.

Najlepszą metodą zmniejszenia lub wyeliminowania monitów logowania jest użycie bibliotek uwierzytelniania Microsoft (MSAL) lub biblioteki opartej na MSAL oraz korzystanie z uwierzytelniania przez brokera. Ta metoda minimalizuje komunikaty logowania i zapewnia najbardziej płynne doświadczenie. Jeśli opieranie się na MSAL nie jest możliwe, aplikacja powinna używać przeglądarki systemowej, aby zminimalizować monity logowania.

W przypadku aplikacji działających w systemie iOS lub Android dostawcy platform mobilnych oferują pewne funkcje, dzięki którym doświadczenie użytkownika jest bardziej bezproblemowe. Google ma wskazówki dla aplikacji na system Android z Dostosowanymi Kartami Chrome. Firma Apple ma wskazówki dotyczące uwierzytelniania użytkownika za pośrednictwem usługi internetowej w aplikacjach systemu iOS. Unikaj używania osadzonych komponentów WebView, ponieważ mogą nie zezwalać na udostępnianie pomiędzy aplikacjami ani w przeglądarce systemowej.

Dwa protokoły uwierzytelniania użytkowników to Security Assertion Markup Language (SAML) 2.0 i OpenID Connect (OIDC). Identyfikator Entra firmy Microsoft w pełni obsługuje aplikacje przy użyciu obu protokołów, dzięki czemu deweloperzy mogą wybrać jedną z nich na podstawie ich wymagań.

Te odniesienia szczegółowo opisują obsługę SAML dla Microsoft Entra ID.

Istnieją pewne ograniczenia w obsłudze protokołu SAML Microsoft Entra ID. W szczególności nie można migrować aplikacji, które wymagają tych możliwości protokołu: obsługa wzorca WS-Trust ActAs i rozwiązania artefaktów SAML.

Chociaż identyfikator Entra firmy Microsoft w pełni obsługuje język SAML dla aplikacji opartych na protokole SAML, Platforma tożsamości Microsoft nie udostępnia bibliotek ani innych narzędzi programistycznych do tworzenia aplikacji przy użyciu języka SAML. W przypadku tworzenia nowych aplikacji zalecamy użycie protokołu OpenID Connect (OIDC) do uwierzytelniania.

Identyfikator Entra firmy Microsoft w pełni obsługuje program OpenID Connect. Firma Microsoft udostępnia biblioteki MSAL, Microsoft Identity Web i Azure SDK, aby ułatwić tworzenie aplikacji OIDC. OpenID Connect (OIDC) na platformie tożsamości Microsoft przedstawia szczegóły dotyczące obsługi OIDC dla Microsoft Entra ID. Biblioteka MSAL automatycznie obsługuje OIDC. Biblioteka MSAL zawsze żąda tokenu identyfikatora OIDC przy każdym żądaniu tokenu, w tym przy żądaniach dostępu aplikacji do zasobów.

Okres istnienia tokenu

Biblioteka MSAL buforuje tokeny ID i dostępu w oparciu o czas wygaśnięcia tokenu dostępu. Ponieważ Microsoft Entra ID inaczej ustala czas życia tokenów ID i tokenów dostępu, możesz otrzymać wygasły token ID z wygasłej pamięci podręcznej MSAL, podczas gdy token dostępu nadal jest w swoim prawidłowym okresie ważności.

Biblioteka MSAL nie odnawia automatycznie tokenów identyfikacyjnych. Biblioteka MSAL odnawia tokeny dostępu w momencie, gdy zbliżają się one do końca okresu ważności, kiedy aplikacja żąda tokenu. W tym momencie MSAL prosi o nowy token ID. Aby zaimplementować OIDC, użyj klauzuli exp (wygasa) w tokenie identyfikacyjnym, aby zaplanować żądanie tokenu tożsamości przy użyciu flagi ForceRefresh w MSAL.

Jeśli nie jest możliwe zbudowanie na MSAL lub bibliotece opartej na MSAL, możesz użyć standardu OpenID Connect, aby uwierzytelnić bieżącego użytkownika. Niektóre funkcje w aplikacjach natywnych mogą nie być możliwe bez korzystania z biblioteki MSAL, takich jak zapewnienie, że aplikacja natywna jest uruchomiona na zarządzanym urządzeniu. Zapoznaj się z artykułem Zwiększanie odporności uwierzytelniania i autoryzacji w aplikacjach klienckich opracowywanych w celu uzyskania wskazówek, gdy nie korzystasz z biblioteki MSAL.

Identyfikator Entra firmy Microsoft implementuje punkt końcowy UserInfo w ramach obsługi standardów OIDC identyfikatora Entra firmy Microsoft przy użyciu określonej ścieżki programu Microsoft Graph (https://graph.microsoft.com/oidc/userinfo). Nie można dodać ani dostosować informacji zwracanych przez UserInfo punkt końcowy. Ponieważ informacje w tokenie identyfikatora są nadzbiorem informacji zwracanych przez wywołanie UserInfo punktu końcowego, zalecamy użycie tokenu identyfikatora zamiast wywoływania punktu końcowego UserInfo .

Uwierzytelnianie użytkowników

Aplikacje interagują z dzierżawcami usługi Microsoft Entra ID w celu uwierzytelniania użytkowników. Aby uwierzytelnić użytkownika, aplikacja kieruje przeglądarkę do https://login.microsoftonline.com/{tenant}/v2.0, gdzie {tenant} jest identyfikatorem lub domeną dzierżawy. Zalecamy jednak, aby niezależni dostawcy oprogramowania (ISV) używali Microsoft Entra ID do tworzenia aplikacji wielodostępnych, które mogą obsługiwać najszerszy zakres klientów. W przypadku aplikacji wielodostępnej aplikacja może nie wiedzieć, z którego najemcy pochodzi użytkownik, dopóki użytkownik się nie uwierzytelni, więc nie będzie możliwe użycie określonego punktu końcowego najemcy.

Aby włączyć aplikacje wielodostępne, Microsoft Entra ID udostępnia dwa niezależne od dzierżawy punkty końcowe OIDC/OAuth 2.0:

  • https://login.microsoftonline.com/common/v2.0 umożliwia użytkownikom uwierzytelnianie aplikacji, gdy należą do dowolnej dzierżawy Microsoft Entra ID lub mają konsumenckie konto Microsoft z serwisów takich jak outlook.com, skype.com, xbox.com, live.com lub Hotmail.com.
  • https://login.microsoftonline.com/organizations/v2.0 umożliwia użytkownikom uwierzytelnianie aplikacji, gdy pochodzą z dowolnej dzierżawy microsoft Entra ID.

Te punkty końcowe umożliwiają każdemu użytkownikowi z dowolnej dzierżawy Microsoft Entra ID uwierzytelnienie się w twojej aplikacji. Jeśli chcesz zezwolić tylko użytkownikom z określonych dzierżaw, zaimplementuj logikę, aby zezwolić tylko użytkownikom z tych dzierżaw na dostęp do aplikacji. Normalna implementacja polega na filtrowaniu użytkowników na podstawie oświadczenia iss (wystawcy) lub tid (identyfikatora dzierżawy) w tokenie w odniesieniu do listy dozwolonych dzierżaw, którą sam utrzymujesz.

Dzierżawy Microsoft Entra ID obsługują użytkowników, którzy mogą być zwykłymi członkami lub użytkownikami gośćmi dzierżawy. Domyślnie możliwości dla użytkowników-gości w dzierżawie są ograniczone. Na przykład użytkownicy-goście nie widzą pełnego profilu innych użytkowników w dzierżawie. Użytkownicy-goście, czasami nazywani użytkownikami firm (B2B), umożliwiają różnym organizacjom współpracę z narzędziami i usługami chronionymi przez usługę Microsoft Entra ID. Przykładowy scenariusz to zaproszenie użytkownika spoza organizacji, aby uzyskał dostęp do pliku w SharePoint w Twoim dzierżawcy. Zazwyczaj użytkownik B2B używa swojego adresu e-mail jako userid. Mogą jednak używać tego samego adresu jako userid w swojej dzierżawie macierzystej. Domyślnie identyfikator Entra firmy Microsoft loguje użytkownika do dzierżawy macierzystej po wprowadzeniu elementu userid.

Aby zalogować użytkownika jako użytkownika B2B, aplikacja musi używać specyficznego punktu końcowego tenanta, w którym użytkownik jest gościem. Chociaż użytkownik może określić dzierżawcę, do którego chce uzyskać dostęp, gdy aplikacja korzysta z https://login.microsoftonline.com/organizations/v2.0 punktu końcowego, użytkownicy mogą mieć trudności z odnalezieniem tej możliwości.

Następne kroki

  • Last updated on