Авторизация приложений, ресурсов и рабочих нагрузок с помощью идентификатора Microsoft Entra

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

• Идентификатор Microsoft Entra для независимых разработчиков программного обеспечения описывает, как использовать эту облачную службу управления удостоверениями и доступом, чтобы сотрудники могли получать доступ к ресурсам с вашим приложением.
• Создание приложений в экосистеме идентификатора Microsoft Entra id описывает, как использовать центр администрирования Microsoft Entra или API Microsoft Graph для регистрации приложений в клиенте идентификатора Microsoft Entra ID.
• Проверка подлинности приложений и пользователей описывает, как приложения используют идентификатор Microsoft Entra для проверки подлинности пользователей и приложений.
• Адаптация токенов помогает встроить безопасность в приложения с использованием токенов идентификации и токенов доступа от Microsoft Entra ID. В нем описываются сведения, которые можно получить в токенах Microsoft Entra ID, и способы их настройки.

Авторизация в приложениях

В этом разделе рассматриваются сценарии, в которых отдельный человек взаимодействует с приложением и направляет его. В разделе "Авторизация в ресурсах ( API) описывается, как API выполняют авторизацию, когда пользователю требуется авторизация для доступа к ресурсу, но идентификатор Microsoft Entra не выполняет окончательную авторизацию. В разделе "Авторизация в рабочих нагрузках " рассматриваются сценарии, в которых приложения или службы работают независимо.

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

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

Процесс авторизации начинается с приложения, использующего OAuth 2.0 для запроса токена доступа из системы Microsoft Entra ID для доступа к определенным операциям в определенном ресурсе для пользователя. В делегированном доступе приложение выступает в качестве делегата для пользователя.

Для разработчиков ресурс может быть API, например Microsoft Graph, служба хранилища Azure или собственный API. Однако большинство API имеют различные операции, такие как чтение и запись. Когда приложение считывает только из API, приложение должно иметь авторизацию только для операций чтения. Этот подход защищает приложение от компрометации и использования для большего доступа, чем предназначено разработчиком. Разработчик следует принципу наименьших привилегий, если приложение авторизует только для операций, необходимых им.

Чтобы указать, какие определенные операции в определенном API требуется приложению, разработчики используют параметр области запроса OAuth 2.0. Конструктор API публикует области, которые приложение может запрашивать в рамках регистрации приложения API. Например, области охвата сервиса Microsoft Power BI включают следующее.

Если приложение считывает только емкости, приложение запрашивает https://analysis.windows.net/powerbi/api/Capacity.Read.All область. Если приложение изменяет емкость, приложение запрашивает https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All область.

Область содержит идентификатор API и идентификатор операции. В https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All области API https://analysis.windows.net/powerbi/api. Операция выполняется Capacity.ReadWrite.All. Учитывая широкий охват и популярность API Microsoft Graph, разработчики могут запрашивать области для Microsoft Graph без компонента API области. Например, Microsoft Graph определяет область https://graph.microsoft.com/Files.Read, с помощью которой приложения могут запрашивать Files.Read вместо использования полного имени области.

Чтобы завершить первую авторизацию, приложение должно иметь авторизацию для доступа к определенным операциям в определенных ресурсах для текущего пользователя, идентификатор Microsoft Entra должен сначала пройти проверку подлинности текущего пользователя. Единый вход (SSO) может удовлетворить эту аутентификацию, или может потребоваться новое взаимодействие с пользователем.

После того как Microsoft Entra ID распознаёт пользователя, он проверяет, авторизовал ли пользователь приложение для запрошенной области доступа. Этот процесс называется предоставлением согласия. Если пользователь предоставил согласие, процесс авторизации может продолжиться. Согласие администратора позволяет администраторам предоставлять согласие для себя и всей организации. Идентификатор Microsoft Entra проверяет, имеет ли приложение согласие администратора для области. Если это предоставлено, процесс авторизации продолжается.

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

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

Если пользователь или администратор не предоставил согласие, пользователь увидит запрос на согласие, как показано в следующем примере.

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

Приложения управляют временем предоставления согласия пользователя. Идентификатор Microsoft Entra поддерживает статическое согласие: когда приложение использует .default область, приложение запрашивает все разрешения, объявленные в регистрации приложения. При наличии статического согласия приложение заранее запрашивает все необходимые разрешения.

Статическое согласие может отпугнуть пользователей и администраторов от утверждения запроса на доступ приложения. Рекомендуется запрашивать необходимые разрешения динамически для базовых функциональных возможностей приложения при запуске приложения и запрашивать дополнительные области при необходимости. Добавочно запрашивать больше областей, так как приложение выполняет операции, требующие этих областей. Этот подход позволяет пользователю лучше понять другие разрешения, которые связаны с временной синхронизацией функций. Для каждого токена доступа к API Microsoft Entra ID включает все полномочия, ранее предоставленные приложению, а не только полномочия в запросе.

Например, приложение может запросить https://graph.microsoft.com/user.read вход пользователя и получить доступ к профилю пользователя при запуске приложения. Позже пользователь выбирает Сохранить в OneDrive, и приложение запрашивает https://graph.microsoft.com/files.readwrite разрешение на запись файла в OneDrive пользователя. Так как пользователь видит, почему приложение запрашивает запись в OneDrive, пользователь предоставляет разрешение, а приложение сохраняет файл в OneDrive пользователя. Затем пользователь закрывает приложение. При следующем запуске приложения он запрашивает https://graph.microsoft.com/user.read. Идентификатор Microsoft Entra возвращает токен доступа с областями https://graph.microsoft.com/user.read и https://graph.microsoft.com/files.readwrite. Запрос токена для https://graph.microsoft.com/files.readwrite области действия не требует согласия, так как пользователь уже его предоставил. Кэширование маркеров в библиотеках проверки подлинности Microsoft (MSAL) автоматически кэширует маркеры на основе предоставленных разрешений. В этом примере после перезапуска приложения запросы к MSAL для получения токена с областью https://graph.microsoft.com/files.readwrite возвращают токен, кэшированный из первоначального запроса приложения на область https://graph.microsoft.com/user.read. Другой вызов идентификатора Microsoft Entra является ненужным.

Динамическое и добавочное согласие не требуют объявленных разрешений во время регистрации приложения. Однако настоятельно рекомендуется объявлять все разрешения, которые приложение может требовать в регистрации приложения для поддержки статического согласия. Администраторы могут предоставить согласие администратора в Центре администрирования Microsoft Entra, используя Microsoft Graph PowerShell или API Microsoft Graph.

Чтобы предоставить согласие администратора для приложения, центр администрирования Microsoft Entra использует статическое согласие, запрашивая разрешение с областью .default для приложения. Администраторы не могут предоставить согласие администратора в Центре администрирования Microsoft Entra приложениям, которым требуется разрешение, если разработчики не объявляют их в регистрации приложений.

Клиенты идентификатора Microsoft Entra могут использовать политики условного доступа для защиты ресурсов (API) и приложений на основе браузера. По умолчанию администраторы не могут применять политики условного доступа к собственным аутентификациям приложений. Администраторы клиента могут нацеливаться на все ресурсы (ранее "Все облачные приложения") или использовать настраиваемые атрибуты безопасности для ориентации на собственные приложения с правилами условного доступа. Даже если она целенаправленно применяется, исполнение политик не охватывает некоторые приложения , которые обращаются к Microsoft Graph или Azure AD Graph.

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

• Приложения, выполняющие поток выполнения 'от имени'
• Приложения, обращаюющиеся к нескольким службам или ресурсам
• Одностраничные приложения, использующие MSAL.js
• Веб-приложения, вызывающие ресурс

Если приложение реализует любой из этих сценариев, ознакомьтесь с руководством разработчика по условному доступу Microsoft Entra.

Бесплатные тенанты идентификатора Microsoft Entra не могут использовать "Условный доступ" (см. требования к лицензированию). Производственный клиент вашей компании может обладать необходимой лицензией. Прежде чем использовать рабочий клиент для тестирования, оцените эти условия . Существует руководство по созданию тестового клиента.

По умолчанию политики условного доступа применяются к приложениям и ресурсам, к которым приложение обращается на уровне приложения. ИТ-администраторы могут применять политики уровня приложений к любому приложению без участия разработчика. Для некоторых приложений и сценариев требуется более подробная степень детализации. Например, финансовому приложению может потребоваться многофакторная проверка подлинности для типичного использования. Однако для транзакции по указанному объему может потребоваться управляемое устройство. Разработчики могут разрешить ИТ-администраторам назначать более строгие политики условного доступа для различных областей приложения, реализуя контекст проверки подлинности условного доступа. Руководство разработчика по контексту проверки подлинности условного доступа является хорошим справочником по этим функциям.

По умолчанию Microsoft Entra ID выдает токены доступа, действительные в течение определенного времени. Приложения никогда не должны предполагать продолжительность существования. Они должны использовать параметр expires_in, который Microsoft Entra ID возвращает вместе с маркером доступа. MSAL автоматически обрабатывает этот сценарий. В течение времени существования маркера доступа пользователь имеет разрешение на доступ к ресурсу в соответствии с условиями во время авторизации.

Задержка между изменением условий и применением политики может беспокоить администраторов и пользователей. Например, когда пользователь теряет устройство, ИТ-администратор может отозвать сеансы пользователя. Однако приложение на потерянном устройстве может продолжать получать доступ к Microsoft Graph для пользователя до истечения срока действия маркера. Оценка непрерывного доступа Майкрософт (CAE) может предотвратить доступ после отзыва сеансов пользователей для приложений, использующих (CAE). Если ваше приложение вызывает Microsoft Graph хотя бы раз в час, вы можете внедрить CAE. Как использовать включенные API с непрерывной оценкой доступа в ваших приложениях предоставляет сведения о реализации.

Если вы не можете использовать MSAL, ваше приложение должно использовать OAuth 2.0 для запроса токенов доступа в Microsoft Entra ID. Платформа идентификации Microsoft и поток кода авторизации OAuth 2.0 предоставляет сведения о реализации потоков, поддерживаемых Microsoft Entra ID.

Если вы создаете приложения для мобильных устройств, просмотрите поддержку политики единого входа и защиты приложений в ваших мобильных приложениях. Узнайте, как научиться поддерживать получение токенов, управление мобильными приложениями Intune (MAM) и политики защиты приложений.

Авторизация в ресурсах (API)

В разделе "Авторизация в приложениях" появилось три необходимых авторизации, когда приложениям требуется доступ к ресурсам для пользователя, но только в первых двух случаях. Пользователь должен иметь авторизацию для доступа к ресурсу, но идентификатор Microsoft Entra не выполняет окончательную авторизацию. Ресурс (API) выполняет авторизацию.

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

• API должны авторизовать приложение для вызова API. Убедитесь, что утверждение маркера scp доступа (область) содержит требуемую область.
• API-интерфейсы должны авторизовать пользователя для доступа к конкретному ресурсу. oid Утверждения (идентификатор объекта) и sub (субъект) в маркере представляют идентификацию пользователя.

Мы рекомендуем использовать утверждения oid и sub для авторизации.

Идентификатор Microsoft Entra реализует парное sub утверждение, поэтому sub утверждение является уникальным идентификатором пользователя для запрашивающего приложения. Тот же пользователь, использующий другое приложение, имеет другое sub утверждение. Утверждение oid является константой для пользователя для всех приложений.

Приложения предоставляют необходимый токен доступа к API, которые идентификатор Microsoft Entra ID защищает в заголовке авторизации запроса http в качестве токена-носителя. API должны полностью проверить полученный маркер, так как маркер не поступает непосредственно из идентификатора Microsoft Entra. Считайте вызывающее приложение ненадежным до проверки токена. Справочник по токенам доступа и статьи справочника по проверке утверждений содержат сведения о проверке токенов доступа Microsoft Entra ID.

Идентификатор Microsoft Entra ID публикует открытые ключи, используемые API для проверки подписи токена. Эти ключи периодически обновляются и всякий раз, когда ситуация требует обновления открытого ключа. Приложение никогда не должно предполагать, что задано расписание для переключения открытого ключа. Переключение ключа подписывания в платформа удостоверений Майкрософт объясняет, как правильно обрабатывать переключение открытого ключа.

Рекомендуется использовать хорошо поддерживаемую библиотеку для проверки токенов. Если вы создаете веб-приложение или API на ASP.NET или ASP.NET Core, используйте Microsoft.Identity.Web для валидации токенов. В статье "Практическое руководство по защищенному веб-API " объясняется, как использовать Microsoft.Identity.Web для защиты API.

Иногда api-интерфейсы должны вызывать другие API. Когда приложение работает для пользователя, API получает делегированный маркер доступа, включающий удостоверение текущего пользователя. Важно, чтобы API доверял только проверенному токену от Microsoft Entra ID, чтобы определить личность текущего пользователя. Этот подход предотвращает компрометацию приложений, так что пользователи олицетворяют других пользователей и получают доступ к ресурсам для другого пользователя. Для такой же защиты, когда один API вызывает другой API, используйте поток OAuth от имени OAuth для получения маркера доступа для вызова API для пользователя, для которого был вызван API. Создайте веб-API, который вызывает веб-API и предлагает шаги для вызова других веб-API пользователем текущего приложения.

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

Авторизация в рабочих нагрузках

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

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

Процесс начинается с нагрузки, запрашивающей токен доступа с областью .default (например, https://graph.microsoft.com/.default). В отличие от делегированного доступа (приложения могут динамически и добавочно запрашивать области), рабочие нагрузки всегда должны использовать статическое согласие и .default область.

Конструкторы API создают разрешения для приложений своего API, добавляя роли в регистрацию приложения API. Эти роли имеют разрешенный тип участников приложения, что позволяет присваивать роли рабочим нагрузкам. Назначьте роли рабочим нагрузкам в Центре администрирования Microsoft Entra или с помощью Microsoft Graph. В Центре администрирования Microsoft Entra согласие администратора для назначенных ролей необходимо перед запуском рабочей нагрузки.

По умолчанию разрешение приложения разрешает рабочим нагрузкам доступ ко всем экземплярам ресурса. Например,https://graph.microsoft.com/user.read.all авторизует рабочую нагрузку для доступа к полному профилю каждого пользователя в клиенте. ИТ-администраторы часто неохотно предоставляют эти широкие разрешения.

Для рабочих нагрузок, обращаюющихся к Microsoft Graph, используйте следующие методы, чтобы ограничить разрешение приложения:

• Microsoft Teams реализует конкретное согласие для ресурса.
• Exchange Online реализует политики доступа к приложениям.
• SharePoint реализует Sites.Selected область применения для согласия на конкретный ресурс.

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

Для рабочих нагрузок, работающих в Microsoft Azure, лучший метод проверки подлинности рабочей нагрузки — это управляемые удостоверения для ресурсов Azure. Функция управляемых удостоверений удаляет необходимость управления учетными данными для рабочей нагрузки. Нет доступных учетных данных. Идентификатор Microsoft Entra полностью управляет учетными данными. Поскольку не нужно управлять учетными данными, риск их компрометации отсутствует.

Благодаря повышенной безопасности, управляемые идентификаторы также повышают устойчивость. Управляемые удостоверения используют долгоживущие маркеры доступа и информацию из Microsoft Entra ID для получения новых маркеров до истечения срока действия текущих. Региональные конечные точки управляемых удостоверений позволяют предотвратить сбои вне региона за счёт консолидации зависимостей служб. Региональные конечные точки помогают сохранить трафик в географической области. Например, если ресурс Azure находится в WestUS2, весь трафик остается в WestUS2.

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

Идентификатор Microsoft Entra поддерживает следующие типы учетных данных клиента:

• Сертификат. Рабочие нагрузки показывают, что у них есть закрытый ключ, подписав утверждение с закрытым ключом. Закрытый ключ не передается в Microsoft Entra ID. Отправляется только утверждение. Рекомендуется использовать сертификаты вместо секретов клиента, так как они более безопасны и часто лучше управляются.
• Федеративные учетные данные. Федерация удостоверений для рабочих нагрузок позволяет рабочим нагрузкам, которые не запущены в Microsoft Azure, использовать удостоверение из другого поставщика удостоверений, GitHub Actions или кластера Kubernetes. Рабочие нагрузки запрашивают токены аналогично для федеративных учетных данных и учетных данных сертификатов. Разница заключается в том, что утверждение, которое представляет собой подписанный веб-токен JSON, поступает от поставщика удостоверений федерации.
• Секрет клиента. Иногда называется паролем приложения, секрет клиента — это строковое значение, которое рабочая нагрузка может использовать для идентификации себя. Текстовое значение секрета отправляется из рабочей нагрузки в Microsoft Entra ID в запросе POST для токена. Секреты клиента менее безопасны, чем сертификаты или федерация удостоверений рабочей нагрузки. Если рабочая нагрузка использует секреты, следуйте этим рекомендациям по управлению секретами.

Помимо Microsoft Entra ID, семейство продуктов Microsoft Entra включает Microsoft Entra Workload ID. Идентификатор рабочей нагрузки Microsoft Entra имеет следующие премиум-функции для усиления безопасности рабочих нагрузок.

• Условный доступ поддерживает политики, основанные на расположении или рисках, для идентификаторов рабочих нагрузок.
• Защита идентификации Microsoft Entra предоставляет отчеты о скомпрометированных учетных данных, аномальных входах и подозрительных изменениях учетных записей.
• Обзоры доступа позволяют делегировать задачи нужным людям, сосредотачиваясь на наиболее важных привилегированных ролях.
• Рекомендации по поддержанию работоспособности приложений предлагают способы устранения недостатков в управлении безопасностью идентификаторов в вашем портфеле приложений и улучшения безопасности и устойчивости арендатора.

Рабочие нагрузки могут поддерживать непрерывную оценку доступа (CAE), если они вызывают Microsoft Graph по крайней мере один раз в час. Для поддержки ЦС рабочая нагрузка должна быть одним приложением клиента и приложением, зарегистрированным в клиенте, где он обращается к Microsoft Graph. Если рабочая нагрузка соответствует этим требованиям, ознакомьтесь с этим примером действий по реализации.

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

• Идентификатор Microsoft Entra для независимых разработчиков программного обеспечения описывает, как использовать эту облачную службу управления удостоверениями и доступом, чтобы сотрудники могли получать доступ к ресурсам с вашим приложением.
• Создание приложений в экосистеме идентификатора Microsoft Entra id описывает, как использовать центр администрирования Microsoft Entra или API Microsoft Graph для регистрации приложений в клиенте идентификатора Microsoft Entra ID.
• Проверка подлинности приложений и пользователей описывает, как приложения используют идентификатор Microsoft Entra для проверки подлинности пользователей и приложений.
• Адаптация токенов помогает встроить безопасность в приложения с использованием токенов идентификации и токенов доступа от Microsoft Entra ID. В нем описываются сведения, которые можно получить в токенах Microsoft Entra ID, и способы их настройки.