Общие сведения о доступе только для приложений
Когда приложение напрямую обращается к ресурсу, например Microsoft Graph, его доступ не ограничивается файлами или операциями, доступными для одного пользователя. Приложение вызывает API непосредственно с помощью собственного удостоверения, а пользователь или приложение с правами администратора должны авторизовать его для доступа к ресурсам. Этот сценарий является доступом только для приложений.
Когда следует использовать доступ только для приложений?
В большинстве случаев доступ только для приложений является более широким и более мощным, чем делегированный доступ, поэтому при необходимости следует использовать только доступ только для приложений. Обычно это правильный выбор, если:
- Приложение должно выполняться автоматически без ввода пользователем. Например, ежедневный скрипт, который проверяет сообщения электронной почты из определенных контактов и отправляет автоматические ответы.
- Приложение должно получить доступ к ресурсам, принадлежащим нескольким разным пользователям. Например, приложению защиты от потери данных или резервному копированию может потребоваться получить сообщения из разных каналов чата, каждый из которых имеет разные участники.
- Вы найдете себя заманчивым хранить учетные данные локально и разрешить приложению войти в систему как пользователя или администратора.
В отличие от этого, вы никогда не должны использовать доступ только для приложений, когда пользователь обычно войдет в систему для управления собственными ресурсами. Эти типы сценариев должны использовать делегированный доступ, чтобы быть наименее привилегированным.
Авторизация приложения для вызовов только приложений
Чтобы совершать вызовы только для приложений, необходимо назначить клиентское приложение соответствующим ролям приложения. Роли приложений также называются разрешениями только для приложений. Они роли приложений, так как они предоставляют доступ только в контексте приложения ресурсов, определяющего роль.
Например, чтобы прочитать список всех команд, созданных в организации, необходимо назначить приложение роли приложения Microsoft Graph Team.ReadBasic.All . Эта роль приложения предоставляет возможность считывать эти данные, если Microsoft Graph — это приложение ресурсов. Это назначение не назначает клиентскому приложению роль Teams, которая может позволить ему просматривать эти данные через другие службы.
Разработчику необходимо настроить все необходимые разрешения только для приложений, которые также называются ролями приложений при регистрации приложения. Вы можете настроить запрошенные разрешения приложения только для приложений с помощью портал Azure или Microsoft Graph. Доступ только для приложений не поддерживает динамическое согласие, поэтому вы не можете запрашивать отдельные разрешения или наборы разрешений во время выполнения.
После настройки всех необходимых разрешений приложению он должен получить согласие администратора для доступа к ресурсам. Например, только пользователи с ролью администратора привилегированных ролей могут предоставлять разрешения только для приложений (роли приложения) для API Microsoft Graph. Пользователи с другими ролями администратора, например администратор приложений и администратор облачных приложений, могут предоставлять разрешения только для приложений для других ресурсов.
Администраторы могут предоставлять разрешения только для приложений с помощью портал Azure или путем программного создания грантов через API Microsoft Graph. Вы также можете запрашивать интерактивное согласие в приложении, но этот параметр не предпочтительнее, так как доступ только для приложений не требует пользователя.
Пользователи потребителей с учетными записями Майкрософт, такие как Outlook.com или учетные записи Xbox Live, никогда не могут авторизовать доступ только для приложений.
Всегда следуйте принципу наименьших привилегий: никогда не следует запрашивать роли приложения, которые не нужны вашему приложению. Этот принцип помогает ограничить риск безопасности, если приложение скомпрометировано и упрощает предоставление администраторам доступа к приложению. Например, если приложению необходимо определить пользователей, не читая подробные сведения о профиле, вместо этого User.Read.Allследует запросить более ограниченную роль приложения Microsoft GraphUser.ReadBasic.All.
Проектирование и публикация ролей приложения для службы ресурсов
Если вы создаете службу на идентификаторе Microsoft Entra, который предоставляет API для вызова других клиентов, вы можете поддерживать автоматический доступ с ролями приложения (разрешения только для приложений). Роли приложений можно определить в разделе ролей приложений регистрации приложения в Центре администрирования Microsoft Entra. Дополнительные сведения о создании ролей приложения см. в разделе "Объявление ролей" для приложения.
При предоставлении ролей приложений другим пользователям предоставьте четкое описание сценария администратору, который собирается назначить их. Роли приложений обычно должны быть максимально узкими и поддерживать определенные функциональные сценарии, так как доступ только для приложений не ограничен правами пользователя. Избегайте предоставления одной роли, которая предоставляет полный read или полный read/write доступ ко всем API-интерфейсам и ресурсам вашей службы.
Примечание.
Роли приложений (разрешения только для приложений) также можно настроить для поддержки назначения пользователям и группам. Убедитесь, что роли приложения настроены правильно для вашего сценария доступа. Если вы планируете использовать роли приложений API для доступа только для приложений, выберите приложения в качестве только разрешенных типов элементов при создании ролей приложения.
Как работает доступ только для приложений?
Самое главное, что следует помнить о доступе только для приложений, заключается в том, что вызывающее приложение действует от своего имени и в качестве собственного удостоверения. Взаимодействие с пользователем отсутствует. Если приложению назначена определенная роль приложения для ресурса, приложение имеет полный ограниченный доступ ко всем ресурсам и операциям, управляемым этой ролью приложения.
После назначения приложения одной или нескольким ролям приложений (разрешения только для приложений) он может запросить маркер только для приложений из идентификатора Microsoft Entra с помощью потока учетных данных клиента или любого другого поддерживаемого потока проверки подлинности. Назначенные роли добавляются в roles утверждение маркера доступа приложения.
В некоторых сценариях удостоверение приложения может определить, предоставляется ли доступ, аналогично правам пользователя в делегированном вызове. Например, Application.ReadWrite.OwnedBy роль приложения предоставляет приложению возможность управлять субъектами-службами, принадлежащими самому приложению.
Пример доступа только для приложений — автоматическое уведомление по электронной почте с помощью Microsoft Graph
В следующем примере показан реалистичный сценарий автоматизации.
Алиса хочет уведомить команду по электронной почте каждый раз, когда папка отчетов отделов, которая находится в общей папке Windows, регистрирует новый документ. Алиса создает запланированную задачу, которая запускает скрипт PowerShell для изучения папки и поиска новых файлов. Затем скрипт отправляет сообщение электронной почты с помощью почтового ящика, защищенного API ресурсов Microsoft Graph.
Скрипт выполняется без взаимодействия с пользователем, поэтому система авторизации проверяет только авторизацию приложения. Exchange Online проверяет, предоставлено ли клиенту разрешение приложения (роль приложения) Mail.Send администратором. Если Mail.Send приложение не предоставлено, exchange Online завершится сбоем запроса.
| POST /users/{id}/{userPrincipalName}/sendMail | Клиентское приложение, предоставленное Mail.Send | Клиентское приложение не предоставлено Mail.Send |
|---|---|---|
| Сценарий использует почтовый ящик Алисы для отправки сообщений электронной почты. | 200 — предоставлен доступ. Администратор разрешил приложению отправлять почту как любой пользователь. | 403 - Несанкционированное. Администратор не разрешил этому клиенту отправлять сообщения электронной почты. |
| Скрипт создает выделенный почтовый ящик для отправки сообщений электронной почты. | 200 — предоставлен доступ. Администратор разрешил приложению отправлять почту как любой пользователь. | 403 - Несанкционированное. Администратор не разрешил этому клиенту отправлять сообщения электронной почты. |
В этом примере показана простая иллюстрация авторизации приложения. Рабочая служба Exchange Online поддерживает множество других сценариев доступа, таких как ограничение разрешений приложения на определенные почтовые ящики Exchange Online.