Поделиться через

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

  • Статья

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

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

Токены

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

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

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

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

Схема конфиденциального клиента с паролем

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

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

Сертификаты

Схема конфиденциального клиента с сертификатом

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

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

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

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

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

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

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

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

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

Схема потока кода устройства

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

  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 находится либо queryfragment). Некоторые браузеры ограничивают длину URL-адреса в строке адреса, и в случае слишком большой длины происходит сбой браузера. Таким образом, эти маркеры неявного потока не содержат утверждений groups или wids.

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

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

Схема потока On-Behalf-Of

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

  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 и .NET.
  • ROPC не поддерживается в приложениях универсальной платформы Windows (UWP).
  • ROPC в Внешняя идентификация Microsoft Entra поддерживается только для локальных учетных записей.

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

Примечание.

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

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

Схема Встроенной проверки подлинности Windows

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

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

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

  • Совместимость. Встроенная проверка подлинности Windows (IWA) включена для классических приложений .NET, .NET и универсальная платформа Windows (UWP). IWA поддерживает только федеративных пользователей ADFS — пользователи, созданные в Active Directory и поддерживаемые идентификатором Microsoft Entra. Пользователи, созданные непосредственно в идентификаторе Microsoft Entra, без поддержки Active Directory (управляемые пользователи) не могут использовать этот поток проверки подлинности.
  • Многофакторная проверка подлинности (MFA). Проверка подлинности IWA, неактивная (автоматическая) может завершиться ошибкой, если MFA включена в клиенте идентификатора Microsoft Entra ID, и вызов 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 является автоматическим потоком, пользователь приложения должен ранее согласиться на использование приложения или администратора клиента, который ранее предоставил всем пользователям в клиенте согласие на использование приложения. Для удовлетворения любого из этих требований необходимо выполнить одну из этих операций:

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

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