Платформа удостоверений Майкрософт и учетные данные владельца ресурса OAuth 2.0

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

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

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

Важно!

  • Платформа удостоверений Майкрософт поддерживает только грант ROPC в арендаторах Microsoft Entra, а не в личных учетных записях. Это означает, что необходимо использовать конечную точку для конкретного клиента (https://login.microsoftonline.com/{TenantId_or_Name}) или конечную точку organizations.
  • Личные учетные записи, приглашенные в клиент Microsoft Entra, не могут использовать поток ROPC.
  • Учетные записи, у которых нет паролей, не могут войти в систему с помощью ROPC, что означает, что такие функции, как вход SMS, FIDO и приложение Authenticator не будут работать с этим потоком. Если приложению или пользователям требуются эти функции, используйте тип предоставления, отличный от ROPC.
  • Если пользователи должны использовать многофакторную аутентификацию (MFA) для входа в приложение, вместо этого они будут заблокированы.
  • ROPC не поддерживается в сценариях гибридной федерации идентичности (например, Microsoft Entra ID и AD FS, используемые для аутентификации локальных учетных записей). Если пользователи перенаправляются на весь экран к локальному провайдеру удостоверений, Microsoft Entra ID не может проверить имя пользователя и пароль по этому провайдеру удостоверений. Сетевая аутентификация поддерживается с ROPC, однако.
  • Исключением из сценария федерации гибридного удостоверения будет следующее: политика обнаружения домашнего домена с установленным параметром AllowCloudPasswordValidation на TRUE позволит потоку ROPC работать для федеративных пользователей при синхронизации локального пароля с облаком. Дополнительные сведения см. в разделе Включение прямой проверки подлинности ROPC федеративных пользователей для устаревших приложений.
  • Пароли с начальными или конечными пробелами не поддерживаются потоком ROPC.

Как перейти от ROPC

По мере того как многофакторная проверка подлинности становится более распространенной, некоторые веб-API Майкрософт будут принимать только маркеры доступа, если они прошли требования MFA. Приложения и тестовые установки, использующие ROPC, будут заблокированы. Microsoft Entra либо не выдает маркер, либо ресурс отклонит запрос.

Если вы используете ROPC для получения токенов для вызова защищённых подчинённых API, перейдите на более безопасную стратегию получения токенов.

Когда контекст пользователя доступен

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

  • Для веб-приложений:
    • Если проверка подлинности выполняется во фронтенде, см. одностраничное приложение.
    • Если проверка подлинности выполняется в серверной части, см. веб-приложения.
  • Веб-API не могут отображать браузер. Вместо этого они должны вернуть запрос на подтверждение клиентскому приложению. Дополнительные сведения см. в веб-API и сложных пользователей в веб-API.
  • Настольные приложения должны использовать аутентификацию на основе брокера. Брокеры используют проверку подлинности на основе браузера, чтобы они могли применять MFA, а также включить наиболее безопасную защиту.
  • Мобильные приложения также должны быть настроены для использования аутентификации на основе брокера (Authenticator, Company Portal).

Если контекст пользователя недоступен

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

  • Скрипт, выполняющийся в рамках конвейера CI.
  • Служба, требующая вызова ресурса от имени себя, без сведений о пользователе.

Разработчики приложений должны использовать аутентификацию с помощью учетной записи службы, которая показана в примерах демон-приложений . MFA не применяется к субъектам-службам.

Существует несколько способов проверки подлинности в качестве субъекта-службы:

  • Если ваше приложение работает в инфраструктуре Azure, используйте управляемое удостоверение. Управляемое удостоверение устраняет затраты на обслуживание и смену секретов и сертификатов.
  • Если ваше приложение работает в системе, управляемой другим поставщиком удостоверений, совместимым с OAuth2, например, GitHub, используйте федеративные учетные данные удостоверений.
  • Если вы не можете использовать управляемое удостоверение или федеративное удостоверение, используйте сертификатные учетные данные.

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

Не используйте проверку подлинности субъекта-службы, если контекст пользователя доступен. Доступ, предоставляемый только приложениям, по сути, является высоким уровнем привилегий, часто предоставляя доступ на уровне арендатора и потенциально позволяя злоумышленнику получать доступ к данным любого пользователя.

Схема протокола

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

схема , показывающая поток учетных данных владельца ресурса

Запрос авторизации

Поток ROPC — это единичный запрос: он отправляет идентификацию клиента и учетные данные пользователя поставщику удостоверений, а в ответ получает токены. Перед этим клиент должен запросить адрес электронной почты пользователя (UPN) и пароль. Сразу после успешного запроса клиент должен безопасно отменить учетные данные пользователя из памяти. Он никогда не должен сохранять их.

HTTP
// Line breaks and spaces are for legibility only.  This is a public client, so no secret is required.

POST {tenant}/oauth2/v2.0/token
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=user.read%20openid%20profile%20offline_access
&username=MyUsername@myTenant.com
&password=SuperS3cret
&grant_type=password
Параметр Состояние Описание
tenant Обязательно Арендатор каталога, в который вы хотите зарегистрировать пользователя. Клиент может быть в формате GUID или понятного имени. Однако его параметр не может быть задан как common или consumers, но может иметь значение organizations.
client_id Обязательно Идентификатор приложения (клиента), который на странице центра администрирования Microsoft Entra — регистрация приложений назначен вашему приложению.
grant_type Обязательно Необходимо задать значение password.
username Обязательно Адрес электронной почты пользователя.
password Обязательно Пароль пользователя.
scope Рекомендуется Разделенный пробелом список областей или разрешений, необходимых приложению. В интерактивном потоке администратор или пользователь должны заранее согласиться на эти области.
client_secret Иногда требуется Если ваше приложение является общедоступным клиентом, нельзя включать client_secret или client_assertion. Если приложение является конфиденциальным клиентом, его необходимо включить.
client_assertion Иногда требуется Другая форма client_secret, созданная с помощью сертификата. Дополнительные сведения см. в данные учетной записи сертификата.

Успешный ответ проверки подлинности

В следующем примере показан успешный ответ маркера:

JSON
{
    "token_type": "Bearer",
    "scope": "User.Read profile openid email",
    "expires_in": 3599,
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD..."
}
Параметр Формат Описание
token_type Струна Всегда задано значение Bearer.
scope Разделенные пробелами строки Если маркер доступа был возвращен, этот параметр содержит допустимые области маркера доступа.
expires_in int Количество секунд, в течение которых действителен входящий маркер доступа.
access_token Непрозрачная строка Выданы для областей , которые были запрошены.
id_token JWT Выдается, если исходный параметр scope включал область openid.
refresh_token Непрозрачная строка Выдано, если исходный параметр scope включал offline_access.

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

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

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

Ответ на ошибку

Если пользователь не предоставил правильное имя пользователя или пароль, или клиент не получил запрошенное согласие, проверка подлинности завершится ошибкой.

Ошибка Описание Действие клиента
invalid_grant Сбой проверки подлинности Учетные данные были неверными или клиент не имеет согласия на запрошенные области. Если области не предоставлены, будет возвращена ошибка consent_required. Чтобы устранить эту ошибку, клиент должен направить пользователя на интерактивную подсказку с помощью веб-представления или браузера.
invalid_request Запрос был неправильно создан Тип предоставления не поддерживается в контекстах проверки подлинности /common или /consumers. Вместо этого используйте /organizations или идентификатор клиента.

Подробнее

Пример реализации потока ROPC см. в примере кода консольного приложения .NET на сайте GitHub.