Przepływ logowania aplikacji przy użyciu Platforma tożsamości Microsoft

W tym temacie omówiono podstawowy przepływ logowania dla aplikacji internetowych, klasycznych i mobilnych przy użyciu Platforma tożsamości Microsoft. Zobacz Scenariusze dotyczące przepływów uwierzytelniania i aplikacji, aby dowiedzieć się więcej o scenariuszach logowania obsługiwanych przez Platforma tożsamości Microsoft.

Przepływ logowania aplikacji internetowej

Gdy użytkownik przechodzi w przeglądarce do aplikacji internetowej, następuje:

  • Aplikacja internetowa określa, czy użytkownik jest uwierzytelniony.
  • Jeśli użytkownik nie jest uwierzytelniony, aplikacja internetowa deleguje się do Azure AD, aby zalogować się do użytkownika. To logowanie będzie zgodne z zasadami organizacji, co może oznaczać monit o wprowadzenie poświadczeń przez użytkownika przy użyciu uwierzytelniania wieloskładnikowego (czasami nazywanego uwierzytelnianiem dwuskładnikowym lub 2FA) lub w ogóle nie używa hasła (na przykład przy użyciu Windows Hello).
  • Użytkownik jest proszony o zgodę na dostęp, którego potrzebuje aplikacja kliencka. Dlatego aplikacje klienckie muszą być zarejestrowane w Azure AD, aby Platforma tożsamości Microsoft mogły dostarczać tokeny reprezentujące dostęp, do którego użytkownik wyraził zgodę.

Po pomyślnym uwierzytelnieniu użytkownika:

  • Platforma tożsamości Microsoft wysyła token do aplikacji internetowej.
  • Plik cookie jest zapisywany, skojarzony z domeną Azure AD, który zawiera tożsamość użytkownika w pliku cookie jar przeglądarki. Przy następnym użyciu przeglądarki w celu przejścia do punktu końcowego autoryzacji Platforma tożsamości Microsoft przeglądarka wyświetli plik cookie, aby użytkownik nie musiał się ponownie zalogować. Jest to również sposób osiągnięcia logowania jednokrotnego. Plik cookie jest generowany przez Azure AD i może być zrozumiały tylko przez Azure AD.
  • Następnie aplikacja internetowa weryfikuje token. Jeśli walidacja zakończy się pomyślnie, aplikacja internetowa wyświetli chronioną stronę i zapisze plik cookie sesji w pliku cookie w pliku cookie przeglądarki. Gdy użytkownik przejdzie do innej strony, aplikacja internetowa wie, że użytkownik jest uwierzytelniany na podstawie pliku cookie sesji.

Poniższy diagram sekwencji podsumowuje tę interakcję:

Proces uwierzytelniania aplikacji internetowej

Jak aplikacja internetowa określa, czy użytkownik jest uwierzytelniony

Deweloperzy aplikacji internetowej mogą wskazać, czy wszystkie lub tylko niektóre strony wymagają uwierzytelniania. Na przykład w ASP.NET/ASP.NET Core jest to wykonywane przez dodanie atrybutu [Authorize] do akcji kontrolera.

Ten atrybut powoduje, że ASP.NET sprawdzić obecność pliku cookie sesji zawierającego tożsamość użytkownika. Jeśli plik cookie nie jest obecny, ASP.NET przekierowuje uwierzytelnianie do określonego dostawcy tożsamości. Jeśli dostawca tożsamości jest Azure AD, aplikacja internetowa przekierowuje uwierzytelnianie do https://login.microsoftonline.comprogramu , w którym zostanie wyświetlone okno dialogowe logowania.

Jak aplikacja internetowa deleguje logowanie do Platforma tożsamości Microsoft i uzyskuje token

Uwierzytelnianie użytkownika odbywa się za pośrednictwem przeglądarki. Protokół OpenID używa standardowych komunikatów protokołu HTTP.

  • Aplikacja internetowa wysyła protokół HTTP 302 (przekierowanie) do przeglądarki w celu użycia Platforma tożsamości Microsoft.
  • Po uwierzytelnieniu użytkownika Platforma tożsamości Microsoft wysyła token do aplikacji internetowej przy użyciu przekierowania za pośrednictwem przeglądarki.
  • Przekierowanie jest udostępniane przez aplikację internetową w postaci identyfikatora URI przekierowania. Ten identyfikator URI przekierowania jest zarejestrowany w obiekcie aplikacji Azure AD. Może istnieć kilka identyfikatorów URI przekierowania, ponieważ aplikacja może zostać wdrożona pod kilkoma adresami URL. Dlatego aplikacja internetowa będzie również musiała określić identyfikator URI przekierowania do użycia.
  • Azure AD sprawdza, czy identyfikator URI przekierowania wysłany przez aplikację internetową jest jednym z zarejestrowanych identyfikatorów URI przekierowania dla aplikacji.

Przepływ logowania aplikacji klasycznych i mobilnych

Przepływ opisany powyżej ma zastosowanie, z niewielkimi różnicami, do aplikacji klasycznych i mobilnych.

Aplikacje klasyczne i mobilne mogą używać osadzonej kontrolki sieci Web lub przeglądarki systemowej do uwierzytelniania. Na poniższym diagramie pokazano, jak aplikacja klasyczna lub mobilna używa biblioteki uwierzytelniania firmy Microsoft (MSAL) do uzyskiwania tokenów dostępu i wywoływania internetowych interfejsów API.

Aplikacja klasyczna, jak się wydaje

Biblioteka MSAL używa przeglądarki do pobierania tokenów. Podobnie jak w przypadku aplikacji internetowych, uwierzytelnianie jest delegowane do Platforma tożsamości Microsoft.

Ponieważ Azure AD zapisuje ten sam plik cookie tożsamości w przeglądarce, co w przypadku aplikacji internetowych, jeśli natywna lub mobilna aplikacja używa przeglądarki systemu, natychmiast otrzyma logowanie jednokrotne z odpowiednią aplikacją internetową.

Domyślnie biblioteka MSAL używa przeglądarki systemowej. Wyjątek dotyczy .NET Framework aplikacji klasycznych, w których osadzona kontrolka jest używana do zapewnienia bardziej zintegrowanego środowiska użytkownika.

Następne kroki

W innych tematach obejmujących podstawy uwierzytelniania i autoryzacji:

  • Zobacz Uwierzytelnianie a autoryzacja, aby dowiedzieć się więcej o podstawowych pojęciach związanych z uwierzytelnianiem i autoryzacją w Platforma tożsamości Microsoft.
  • Zobacz Tokeny zabezpieczające , aby dowiedzieć się, jak tokeny dostępu, tokeny odświeżania i tokeny identyfikatorów są używane w uwierzytelnianiu i autoryzacji.
  • Zobacz Model aplikacji, aby dowiedzieć się więcej na temat procesu rejestrowania aplikacji, aby umożliwić integrację z Platforma tożsamości Microsoft.

Aby dowiedzieć się więcej o przepływie logowania aplikacji:

  • Zobacz Przepływy uwierzytelniania i scenariusze aplikacji, aby dowiedzieć się więcej o innych scenariuszach uwierzytelniania użytkowników obsługiwanych przez Platforma tożsamości Microsoft.
  • Zobacz biblioteki MSAL, aby dowiedzieć się więcej o bibliotekach firmy Microsoft, które ułatwiają tworzenie aplikacji, które współpracują z kontami Microsoft, kontami Azure AD i Azure AD użytkowników B2C we wszystkich, usprawnionych modelach programowania.