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

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

Токены

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

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

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

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

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

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

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

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

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

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

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.0 позволяет получать доступ к ресурсам, размещенным в Интернете, с помощью удостоверения приложения. Этот тип предоставления разрешения часто используется для взаимодействия между серверами, которое должно выполняться в фоновом режиме без непосредственного взаимодействия с пользователем. Такие типы приложений часто называют управляющими программами или учетными записями служб.

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

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

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

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

Сертификаты

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

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

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

• Зарегистрировано с помощью идентификатора Microsoft Entra
• Передается при создании объекта конфиденциального клиентского приложения в коде

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

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

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

Поток кода устройства OAuth 2.0 позволяет пользователям выполнять входные устройства, такие как смарт-телевизоры, устройства Интернета вещей и принтеры. Для интерактивной проверки подлинности с помощью идентификатора Microsoft Entra требуется веб-браузер. Если устройство или операционная система не предоставляют веб-браузер, поток кода устройства позволяют пользователю использовать другое устройство, такое как компьютер или мобильный телефон, для входа в интерактивном режиме.

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

Рассмотрим схему ниже.

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

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

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

Неявное предоставление разрешения

Поток неявного предоставления был заменен потоком кода авторизации PKCE в качестве предпочтительного и более безопасного потока предоставления маркеров для клиентских одностраничных приложений (SPAs)

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

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

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

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

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

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

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

Рассмотрим схему ниже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Многофакторная проверка подлинности (MFA)

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

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

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

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

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

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

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

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

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

  ИЛИ

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

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

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

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

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

Сведения о получении и кэшировании маркеров, используемых в этих потоках: