Поддержка потоков аутентификации в MSAL

Библиотека аутентификации Майкрософт (MSAL) поддерживает использование нескольких разрешений авторизации и связанных потоков маркеров разными приложениями и в разных сценариях.

Поток проверки подлинности Включает Поддерживаемые типы приложений
Код авторизации Вход пользователя и доступ к веб-API от имени пользователя. * Классические
* Мобильные
* Одностраничные (SPA) (требует PKCE)
* Веб
Учетные данные клиента Доступ к веб-API путем использования удостоверения самого приложения. Обычно используется для обмена данными между серверами и автоматизированными скриптами, не требующим взаимодействия с пользователем. Управляющая программа
Код устройства Вход пользователя и доступ к веб-API от имени пользователя на устройствах с ограниченными возможностями ввода, например на смарт-телевизорах или устройствах Интернета вещей. Также используется приложениями командной строки (CLI). Классические и мобильные
Неявное разрешение Вход пользователя и доступ к веб-API от имени пользователя. Поток неявного предоставления разрешения больше не рекомендуется — используйте код авторизации с PKCE. * Одностраничные (SPA)
* Веб
Поток On-Behalf-Of (OBO) Доступ из "вышестоящего" веб-API к "нижестоящему" веб-API от имени пользователя. Удостоверение пользователя и делегированные разрешения передаются нижестоящему API от вышестоящего. Веб-интерфейс API
Имя пользователя/пароль (ROPC) Позволяет приложению войти в систему, напрямую обрабатывая пароль. Поток ROPC НЕ рекомендуется. Классические и мобильные
Встроенная проверка подлинности Windows (IWA) Позволяет приложениям на компьютерах, подключенных к домену или Azure Active Directory (Azure AD), получать маркер автоматически (без взаимодействия с пользовательским интерфейсом). Классические и мобильные

Токены

Приложение может использовать один или несколько потоков аутентификации. Каждый поток использует определенные типы маркеров для аутентификации, авторизации и обновления маркеров, а некоторые также используют код авторизации.

Поток или действие аутентификации Требования Маркер идентификации Маркер доступа Маркер обновления Код авторизации
Поток кода авторизации x x x x
Учетные данные клиента x (только для приложений)
Поток кода устройства x x x
Неявный поток x x
Поток On-Behalf-Of Twitter, x x x
Имя пользователя/пароль (ROPC) имя пользователя, пароль x x x
Гибридный поток OIDC x x
Активация маркера обновления маркер обновления x x x

Интерактивные и неинтерактивные методы проверки подлинности

Некоторые из этих потоков поддерживают как интерактивное, так и неинтерактивное получение маркера.

  • Интерактивный — сервер авторизации может потребовать от пользователя ввести данные. Например, для входа выполнить многофакторную проверку подлинности (MFA) или предоставить согласие на дополнительные разрешения для доступа к ресурсам.
  • Неинтерактивный — возможно, пользователю не потребуется вводить данные. Такой подход также называется "автоматическим" получением маркера — приложение пытается получить маркер с помощью метода, который может не предусматривать ввод со стороны пользователя.

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

Код авторизации

Предоставление кода авторизации OAuth 2.0 может использоваться веб-приложениями, одностраничными приложениями (SPA) и собственными (мобильными и классическими) приложениями для доступа к защищенным ресурсам, например веб-API.

Когда пользователи входят в веб-приложения, приложение получает код авторизации, с помощью которого оно может получить маркер доступа для вызова веб-API.

Diagram of authorization code flow

На предыдущей схеме приложение:

  1. Запрашивает код авторизации, который используется для получения маркера доступа.
  2. Использует маркер доступа для вызова веб-API, Microsoft Graph.

Ограничения для кода авторизации

  • Одностраничные приложения требуют ключ проверки для обмена кодом (PKCE) при использовании потока предоставления кода авторизации. PKCE поддерживается MSAL.

  • Спецификация OAuth 2.0 требует использовать код авторизации для получения маркера доступа только единожды.

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

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

Учетные данные клиента

Поток учетных данных клиента OAuth 2 позволяет получать доступ к ресурсам, размещенным в Интернете, с помощью удостоверения приложения. Этот тип предоставления разрешения часто используется для взаимодействия между серверами, которое должно выполняться в фоновом режиме без непосредственного взаимодействия с пользователем. Такие типы приложений часто называют управляющими программами или учетными записями служб.

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

Секреты приложений

Diagram of confidential client with password

На предыдущей схеме приложение:

  1. получает маркер с помощью секрета приложения или учетных данных пароля;
  2. использует маркер для выполнения запросов к ресурсу.

Сертификаты

Diagram of confidential client with cert

На предыдущей схеме приложение:

  1. получает маркер с помощью учетных данных сертификата;
  2. использует маркер для выполнения запросов к ресурсу.

Эти учетные данные клиента должны быть:

  • зарегистрированы в Azure AD.
  • Передается при конструировании конфиденциального объекта клиентского приложения в коде.

Ограничения для учетных данных клиента

Конфиденциальный поток клиента не поддерживается на мобильных платформах, таких как Android, iOS или UWP. Мобильные приложения считаются общедоступными клиентскими приложениями, которые не могут гарантировать конфиденциальность учетных данных.

Код устройства

С помощью потока кода устройства OAuth 2 пользователи могут входить на устройства с ограниченным входом, такие как Smart TV, устройства IoT и принтеры. Для интерактивной проверки подлинности в Azure AD требуется веб-браузер. Если устройство или операционная система не предоставляют веб-браузер, поток кода устройства позволяют пользователю использовать другое устройство, такое как компьютер или мобильный телефон, для входа в интерактивном режиме.

При использовании потока кода устройства приложение получает маркеры с помощью двухэтапного процесса, специально разработанного для этих устройств и операционных систем. В качестве примеров таких приложений можно указать приложения, работающие на устройствах IoT, и инструменты командной строки (CLI).

Diagram of device code flow

На предыдущей схеме показано следующее.

  1. Всякий раз, когда требуется проверка подлинности пользователя, приложение предоставляет код и предлагает пользователю использовать другое устройство (такое как смартфон с выходом в Интернет) для перехода по URL-адресу (например, https://microsoft.com/devicelogin). После этого пользователю будет предложено ввести код и выполнить обычную проверку подлинности, включая запросы согласия и многофакторную проверку подлинности при необходимости.
  2. После успешной проверки подлинности приложение командной строки получает необходимые маркеры через канал обратного вызова и использует их для выполнения необходимых вызовов веб-API.

Ограничения для кода устройства

  • Поток кода устройства доступен только в общедоступных клиентских приложениях.
  • При инициализации общедоступного клиентского приложения в MSAL используйте один из следующих форматов центров:
    • Для арендаторов: https://login.microsoftonline.com/{tenant}/,, где {tenant} — это GUID, представляющий идентификатор арендатора, или имя домена, связанное с арендатором.
    • Для рабочих и учебных учетных записей: https://login.microsoftonline.com/organizations/.

Неявное разрешение

Неявное предоставление разрешения заменено потоком кода авторизации с PCKE (предпочтительный вариант) и более защищенным потоком предоставления маркера для одностраничных приложений (SPA) на стороне клиента. Если вы создаете SPA, используйте поток кода авторизации с PKCE.

Одностраничные веб-приложения, написанные на JavaScript (в том числе с использованием таких платформ, как Angular, Vue.js или React.js), скачиваются с сервера, а их код выполняется прямо в браузере. Так как их код на стороне клиента выполняется в браузере, а не на веб-сервере, они имеют характеристики безопасности, отличающиеся от характеристик традиционных веб-приложений на стороне сервера. До доступности ключа проверки для обмена кодом (PKCE) для потока кода авторизации одностраничные приложения использовали неявное предоставление разрешения, чтобы улучшить скорость реагирования и эффективность получения маркеров доступа.

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

Diagram of implicit grant flow

Ограничения для неявного предоставления разрешения

Поток неявного предоставления разрешения не включает сценарии приложений, которые используют кросс-платформенные среды JavaScript, например Electron или React Native. Подобные кросс-платформенные среды требуют дополнительных возможностей для взаимодействия с собственными классическими и мобильными платформами, на которых они выполняются.

Маркеры, выданные в режиме неявного потока, имеют ограничения по длине, так как они возвращаются в браузер посредством URL-адреса (где response_mode либо query, либо fragment). Некоторые браузеры ограничивают длину URL-адреса в строке адреса, и в случае слишком большой длины происходит сбой браузера. Таким образом, эти маркеры неявного потока не содержат утверждений groups или wids.

Поток On-Behalf-Of (OBO)

Поток проверки подлинности от имени пользователя OAuth 2 используется, когда приложение вызывает службу или веб-API, который в свою очередь должен вызывать другую службу или веб-API. Идея состоит в том, чтобы передать по цепочке запросов делегированное удостоверение пользователя и соответствующие разрешения. Чтобы служба среднего уровня могла выполнять запросы к службе нижнего уровня с проверкой подлинности, служба среднего уровня должна защитить маркер доступа с платформы удостоверений Microsoft от имени пользователя.

Diagram of on-behalf-of flow

На предыдущей схеме показано следующее.

  1. Приложение получает маркер доступа для веб-API.
  2. Клиент (веб-, классическое, мобильное или одностраничное приложение) вызывает защищенный веб-API, добавляя маркер доступа в качестве маркера носителя в заголовок проверки подлинности HTTP-запроса. Веб-API выполняет проверку подлинности пользователя.
  3. Когда клиент вызывает веб-API, веб-API запрашивает другой маркер от имени пользователя.
  4. Защищенный веб-API использует этот маркер для вызова нижестоящего веб-API от имени пользователя. Веб-API также может запрашивать маркеры для других нижестоящих API (но по-прежнему от имени одного и того же пользователя).

Имя пользователя/пароль (ROPC)

Предупреждение

Поток учетных данных владельца ресурсов с паролем (ROPC) НЕ рекомендуется. ROPC требует высокой степени доверия и раскрытия учетных данных. Используйте ROPC только в том случае, если недоступен более защищенный поток. Дополнительные сведения см. в разделе Как решить насущную проблему паролей?.

Предоставление учетных данных пароля владельца ресурса OAuth 2 (ROPC) позволяет приложению обрабатывать вход пользователя, непосредственно используя его пароль. В классическом приложении можно использовать поток имени пользователя и пароля для автоматического получения маркера. При использовании приложения не нужен пользовательский интерфейс.

Некоторым сценариям приложений, таким как DevOps, может быть полезно использование ROPC, но следует избегать его в любом приложении, в котором вы предоставляете интерактивный пользовательский интерфейс для входа пользователей.

Diagram of the username/password flow

На предыдущей схеме приложение:

  1. получает маркер, отправляя имя пользователя и пароль поставщику удостоверений;
  2. вызывает веб-API с помощью маркера.

Чтобы получить маркер в автоматическом режиме на компьютерах Windows, подключенных к доменам, рекомендуется использовать встроенную проверку подлинности Windows (IWA), а не ROPC. Для других сценариев используйте поток кода устройства.

Ограничения для ROPC

К приложениям, использующим поток ROPC, применяются следующие ограничения:

  • Единый вход не поддерживается.
  • Многофакторная проверка подлинности (MFA) не поддерживается.
    • Обратитесь к администратору арендатора, прежде чем использовать этот поток (MFA является часто используемой функцией).
  • Условный доступ не поддерживается.
  • ROPC подходит только для рабочих и учебных учетных записей.
  • Личные учетные записи Майкрософт (MSA) не поддерживаются ROPC.
  • ROPC поддерживается в классических приложениях .NET и приложениях .NET Core.
  • ROPC не поддерживается в приложениях универсальной платформы Windows (UWP).
  • ROPC в Azure AD B2C поддерживается только для локальных учетных записей.

Встроенная проверка подлинности Windows (IWA)

MSAL поддерживает встроенную проверку подлинности Windows (IWA) для классических или мобильных приложений, работающих на компьютерах Windows, которые присоединены к домену или Azure AD. С помощью IWA эти приложения могут получать маркер автоматически, без взаимодействия с пользователем.

Diagram of integrated Windows authentication

На предыдущей схеме приложение:

  1. получает маркер с использованием Встроенной проверки подлинности Windows;
  2. использует маркер для выполнения запросов к ресурсу.

Ограничения для IWA

Совместимость

Встроенная проверка подлинности Windows (IWA) включена для классических приложений .NET, приложений .NET Core и универсальной платформы Windows.

IWA поддерживает только пользователей в федерации AD FS, то есть пользователей, созданных в Active Directory и поддерживаемых Azure AD. Пользователи, созданные непосредственно в Azure AD без поддержки Active Directory (управляемые пользователи), не могут использовать этот поток проверки подлинности.

Многофакторная идентификация (MFA)

Неинтерактивная (автоматическая) аутентификация IWA может завершиться сбоем, если в арендаторе Azure AD включена MFA и запрос MFA выдается Azure AD. В случае сбоя IWA необходимо вернуться к интерактивному методу аутентификации, как описано выше.

Azure AD использует искусственный интеллект для определения необходимости двухфакторной проверки подлинности. Двухфакторная проверка подлинности обычно требуется при входе пользователя из другой страны или региона, при подключении к корпоративной сети без использования VPN и иногда даже при подключении через VPN. Так как разработчики могут не иметь прав для настройки и указания частоты запроса MFA, приложение должно корректно обрабатывать сбой автоматического получения маркера со стороны IWA.

Ограничения URI центров

При создании общедоступного клиентского приложения необходим один из следующих центров.

  • https://login.microsoftonline.com/{tenant}/ — этот центр указывает на однотенантное приложение, вход в которое могут выполнить только пользователи в указанном арендаторе Azure AD. Значение {tenant} может быть идентификатором арендатора в формате GUID или именем домена, связанным с арендатором.
  • https://login.microsoftonline.com/organizations/ — этот центр указывает на мультитенантное приложение, вход в которое могут выполнить пользователи из любого арендатора Azure AD.

Значения центров НЕ должны содержать /common или /consumers, так как личные учетные записи Майкрософт (MSA) не поддерживаются IWA.

Требования к согласию

Так как IWA выполняется автоматически:

  • Пользователь приложения должен быть предварительно одобрен, чтобы использовать приложение.

    OR

  • Администратор клиента должен предварительно одобрить всех пользователей в клиенте для использования приложения.

Для удовлетворения этих требований нужно выполнить одну из таких операций:

  • Вы как разработчик приложений выбрали предоставление разрешения на портале Azure для себя.
  • Администратор арендатора выбрал Предоставление/отзыв согласия администратора для {домен арендатора} на вкладке Разрешения API в разделе регистрации приложения на портале Azure (см. раздел Добавление разрешений для доступа к веб-API).
  • Вы указали способ предоставления пользователями согласия на приложение; см. раздел Запрос согласия отдельного пользователя.
  • Вы указали способ предоставления администратором клиента согласия для приложения; см. раздел Согласие администратора.

Дополнительные сведения о согласии см. в разделе Разрешения и согласие.

Дальнейшие действия

Теперь, когда вы изучили потоки аутентификации, поддерживаемые библиотекой проверки подлинности Майкрософт (MSAL), узнайте о получении и кэшировании маркеров, используемых в этих потоках:

Получение и кэширование маркеров с помощью библиотеки проверки подлинности Майкрософт (MSAL)