Платформа удостоверений Майкрософт и учетные данные владельца ресурса 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.
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.
Служба, требующая вызова ресурса от имени себя, без сведений о пользователе.
Существует несколько способов проверки подлинности в качестве субъекта-службы:
Если ваше приложение работает в инфраструктуре 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_secret
Иногда требуется
Если ваше приложение является общедоступным клиентом, нельзя включать client_secret или client_assertion. Если приложение является конфиденциальным клиентом, его необходимо включить.
Если маркер доступа был возвращен, этот параметр содержит допустимые области маркера доступа.
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 или идентификатор клиента.
Продемонстрировать функции идентификатора Microsoft Entra для модернизации решений удостоверений, реализации гибридных решений и реализации управления удостоверениями.