Потоки проверки подлинности, поддерживаемые в MSAL

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

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

Токены

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

Поток или действие аутентификации	Требования	Маркер идентификации	Маркер доступа	Маркер обновления	Код авторизации
Поток кода авторизации		✅	✅	✅	✅
Учетные данные клиента			✅ (только для приложений)
Поток кода устройства		✅	✅	✅
Неявный поток		✅	✅
Поток 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 позволяет получать доступ к ресурсам, размещенным в Интернете, с помощью удостоверения приложения. Этот тип предоставления обычно используется для взаимодействия между серверами (S2S), которые должны выполняться в фоновом режиме без немедленного взаимодействия со стороны пользователя. Эти типы приложений часто называются управляющих программами или службами.

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

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

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

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

Сертификаты

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

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

Этот тип учетных данных клиента должен иметь следующий вид:

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

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

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

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

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

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

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

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, скачанного и запущенного пользователем-агентом (обычно это веб-браузер).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

Встроенная проверка подлинности Windows была заменена более надежным способом автоматического получения маркеров — WAM. WAM может автоматически входить в систему текущего пользователя Windows. Этот рабочий процесс не требует сложной настройки и работает даже для личных учетных записей (Майкрософт). Внутри брокер Windows (WAM) будет пытаться использовать несколько стратегий, чтобы получить маркер для текущего пользователя Windows, включая IWA и активацию PRT. Это устраняет большинство ограничений IWA.

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

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

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

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

• Совместимость. Интегрированная проверка подлинности Windows (IWA) включена для классических приложений .NET, .NET и универсальная платформа Windows (UWP). IWA поддерживает только федеративных пользователей ADFS — пользователей, созданных в Active Directory и поддерживаемых Microsoft Entra ID. Пользователи, созданные непосредственно в Microsoft Entra ID без поддержки Active Directory (управляемые пользователи), не могут использовать этот поток проверки подлинности.
• Многофакторная проверка подлинности (MFA). Неинтерактивная (автоматическая) проверка подлинности IWA может завершиться ошибкой, если MFA включена в клиенте Microsoft Entra ID и Microsoft Entra ID выдает запрос MFA. В случае сбоя IWA необходимо вернуться к интерактивному методу аутентификации, как описано выше. Microsoft Entra ID использует ИИ для определения необходимости двухфакторной проверки подлинности. Двухфакторная проверка подлинности обычно требуется при входе пользователя из другой страны или региона, при подключении к корпоративной сети без использования VPN и иногда даже при подключении через VPN. Так как конфигурация и частота вызовов MFA могут находиться вне вашего контроля как разработчика, ваше приложение должно корректно обрабатывать сбой автоматического получения маркера IWA.
• Ограничения URI центра. При создании общедоступного клиентского приложения необходим один из следующих центров.
  • https://login.microsoftonline.com/{tenant}/— Этот центр указывает на однотенантное приложение, аудитория входа которого ограничена пользователями в указанном клиенте Microsoft Entra ID. Значение {tenant} может быть идентификатором арендатора в формате GUID или именем домена, связанным с арендатором.
  • https://login.microsoftonline.com/organizations/— Этот центр указывает мультитенантное приложение, аудиторией входа которого являются пользователи в любом клиенте Microsoft Entra ID.
• Личные учетные записи. Значения центра не должны содержать /common или /consumers , так как IWA не поддерживает личные учетные записи Майкрософт (MSA).
• Требования к согласию. Так как IWA является автоматическим потоком, пользователь приложения должен ранее предоставить согласие на использование приложения или администратор клиента должен ранее предоставить согласие всем пользователям в клиенте на использование приложения. Для удовлетворения этих требований нужно выполнить одну из таких операций:
  • Вы, как разработчик приложения, выбрали для себя вариант Предоставить на портале Azure.
  • Администратор арендатора выбрал Предоставление/отзыв согласия администратора для {домен арендатора} на вкладке Разрешения API в разделе регистрации приложения на портале Azure (см. раздел Добавление разрешений для доступа к веб-API).
  • Вы предоставили пользователям способ дать согласие на приложение; См. общие сведения о разрешениях и согласии в платформа удостоверений Майкрософт.
  • Вы предоставили администратору клиента способ предоставления согласия для приложения; См. общие сведения о разрешениях и согласии в платформа удостоверений Майкрософт.

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

Теперь, когда вы изучили потоки проверки подлинности, поддерживаемые MSAL, узнайте о получении и кэшировании маркеров, используемых в этих потоках.