Последовательность входа в приложение с помощью платформы удостоверений Майкрософт

  • Статья

В этом разделе рассматривается базовая последовательность входа в веб-приложения, классические и мобильные приложения с помощью платформы удостоверений Майкрософт. Сведения о сценариях входа, поддерживаемых платформой удостоверений Майкрософт, см. в статье Потоки проверки подлинности и сценарии приложений.

Последовательность входа в веб-приложение

Когда пользователь переходит к веб-приложению в браузере, происходит следующее:

  • Веб-приложение определяет, прошел ли пользователь проверку подлинности.
  • Если пользователь не прошел проверку подлинности, веб-приложение делегирует идентификатор Microsoft Entra для входа в систему. Такая процедура входа соответствует политике организации, а значит, пользователю может быть предложено ввести его учетные данные с использованием многофакторной проверки подлинности (иногда это называется двухфакторной проверкой подлинности или 2FA) или войти без использования пароля (например, через Windows Hello).
  • Пользователю предлагается дать согласие на доступ, который требуется клиентскому приложению. Именно поэтому клиентские приложения должны быть зарегистрированы в идентификаторе Microsoft Entra, чтобы платформа удостоверений Майкрософт могли доставлять маркеры, представляющие доступ, которому пользователь предоставил согласие.

После успешной проверки подлинности пользователя:

  • Платформа удостоверений Майкрософт отправляет маркер веб-приложению.
  • Файл cookie сохраняется, связанный с доменом Microsoft Entra, который содержит удостоверение пользователя в jar-файле cookie браузера. Когда приложение обратится к конечной точке платформы удостоверений Майкрософт через браузер в следующий раз, браузер предъявит этот файл cookie, чтобы пользователю не пришлось выполнять вход еще раз. Таким образом, помимо прочего, обеспечивается единый вход. Файл cookie создается идентификатором Microsoft Entra и может быть понят только идентификатором Microsoft Entra.
  • Затем веб-приложение проверяет полученный маркер. Если проверка даст положительный результат, веб-приложение отобразит защищенную страницу и сохранит файл cookie сеанса в JAR-файл с файлами cookie браузера. Когда пользователь переходит на другую страницу, веб-приложение определяет, прошел ли пользователь проверку подлинности, по этому файлу cookie сеанса.

Этот процесс взаимодействия демонстрирует следующая схема последовательности:

web app authentication process

Как веб-приложение определяет, прошел ли пользователь проверку подлинности

Разработчики веб-приложений могут указать, требуется ли проверка подлинности для всех или только для некоторых страниц. Например, в ASP.NET/ASP.NET Core это можно сделать, добавив к действиям контроллера атрибут [Authorize].

Он заставляет ASP.NET проверять наличие файла cookie сеанса, содержащего идентификатор пользователя. Если файл cookie отсутствует, ASP.NET переадресует проверку подлинности указанному поставщику удостоверений. Если поставщик удостоверений является идентификатором Microsoft Entra, веб-приложение перенаправляет проверку подлинности https://login.microsoftonline.comв , в которой отображается диалоговое окно входа.

Как веб-приложение делегирует вход платформе удостоверений Майкрософт и получает маркер

Проверка подлинности пользователя осуществляется через браузер. Протокол OpenID Connect использует стандартные сообщения по протоколу HTTP.

  • Веб-приложение отправляет в браузер код состояния HTTP 302 (перенаправление), обозначающий переход на платформу удостоверений Майкрософт.
  • Когда аутентификация пользователя будет выполнена, платформа удостоверений Майкрософт отправит маркер веб-приложению, используя перенаправление через браузер.
  • Веб-приложение предоставляет перенаправление в форме URI перенаправления. Этот URI перенаправления зарегистрирован в объекте приложения Microsoft Entra. URI перенаправления может быть несколько, поскольку приложение может быть развернуто по нескольким URL-адресам. В связи с этим веб-приложение также должно указывать, какой URI перенаправления необходимо использовать.
  • Идентификатор Microsoft Entra проверяет, что URI перенаправления, отправленный веб-приложением, является одним из зарегистрированных URI перенаправления для приложения.

Последовательность входа в классические и мобильные приложения

К классическим и мобильным приложениям применяется та же последовательность, которая описана выше, но с небольшими отличиями.

Для проверки подлинности классические и мобильные приложения могут использовать встроенный веб-элемент управления, он же системный браузер. На следующей схеме показано, как классическое или мобильное приложение использует библиотеку проверки подлинности Майкрософт (MSAL) для получения маркеров доступа и вызова веб-API.

Desktop app how it appears to be

MSAL для получения маркеров использует браузер. Как и в случае с веб-приложениями, проверка подлинности перенаправляется на платформу удостоверений Майкрософт.

Так как идентификатор Microsoft Entra сохраняет тот же файл cookie удостоверений в браузере, что и для веб-приложений, если собственное или мобильное приложение использует системный браузер, он немедленно получит единый вход с соответствующим веб-приложением.

По умолчанию MSAL использует системный браузер. Исключение составляют классические приложения .NET Framework, где для более тесного взаимодействия с пользователем используется внедренный элемент управления.

Следующие шаги

Другие статьи по основам проверки подлинности и авторизации:

Дополнительные сведения о последовательности входа в приложение:

  • Сведения о других сценариях проверки подлинности, поддерживаемых платформой удостоверений Майкрософт, см. в статье Потоки проверки подлинности и сценарии приложений.
  • Ознакомьтесь с библиотеками MSAL, чтобы узнать о библиотеках Майкрософт, которые помогают разрабатывать приложения, которые работают с учетными записями Майкрософт, учетными записями Microsoft Entra и пользователями Azure AD B2C в одной упрощенной модели программирования.