Разрешения и согласие в конечной точке Azure Active Directory версии 1.0

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

В этом руководстве используется устаревшая конечная точка Azure Active Directory версии 1.0. Для новых проектов используйте платформу удостоверений Майкрософт.

Azure Active Directory (Azure AD) широко использует разрешения для потоков OAuth и OpenID Connect (OIDC). После получения маркера доступа от Azure AD приложение будет включать утверждения, описывающие разрешения, которые оно имеет в отношении определенного ресурса.

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

Типы разрешений

Azure AD определяет два типа разрешений:

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

Действующие разрешения — это разрешения, которые есть у приложений при запросе API.

• Действующие разрешения приложения являются минимальным пересечением делегированных разрешений, предоставленных приложению (с помощью согласия пользователя), и привилегий авторизованного пользователя. Приложения не могут иметь больше привилегий, чем авторизованный пользователь. В рамках организаций привилегии авторизованного пользователя могут определяться политикой или членством в одной или нескольких ролях администратора. Сведения о том, администраторы каких ролей могут предоставлять делегированные разрешения, см. в статье Разрешения роли администратора в Azure Active Directory. Например, предположим, что вашему приложению предоставлено делегированное разрешение User.ReadWrite.All в Microsoft Graph. Это разрешение номинально предоставляет вашему приложению разрешение читать и обновлять профиль каждого пользователя в организации. Если авторизованный пользователь является глобальным администратором, ваше приложение сможет обновлять профиль каждого пользователя в организации. Тем не менее, если авторизованный пользователь имеет роль администратора, ваше приложение сможет обновить только профиль авторизованного пользователя. Оно не сможет обновлять профили других пользователей в организации, потому что пользователь, от имени которого это приложение действует, не имеет таких привилегий.
• Для разрешений приложений действующие разрешения вашего приложения представляют собой полный уровень привилегий, подразумеваемых разрешением. Например, приложение, имеющее разрешение User.ReadWrite.All, может обновлять профиль каждого пользователя в организации.

Атрибуты разрешений

Разрешения в Azure AD имеют ряд свойств, которые помогают пользователям, администраторам или разработчикам приложений принимать обоснованные решения в отношении того, к какому ресурсу предоставляет доступ это разрешение.

Примечание

Разрешения, которые предоставляет приложение Azure AD или субъект служба, можно просмотреть с помощью портала Azure или PowerShell. Попробуйте выполнить этот сценарий, чтобы просмотреть разрешения, предоставленные Microsoft Graph.

Connect-AzureAD

# Get OAuth2 Permissions/delegated permissions
(Get-AzureADServicePrincipal -filter "DisplayName eq 'Microsoft Graph'").OAuth2Permissions

# Get App roles/application permissions
(Get-AzureADServicePrincipal -filter "DisplayName eq 'Microsoft Graph'").AppRoles

Имя свойства	Описание	Пример
ID	Значение GUID, которое уникальным образом идентифицирует это разрешение.	570282fd-fa5c-430d-a7fd-fc8dc98a9dca
IsEnabled	Указывает, доступно ли это разрешение для использования.	Да
Type	Указывает, требуется ли для этого разрешения согласие пользователя или администратора.	Пользователь
AdminConsentDescription	Описание, отображается для администраторов в процессе предоставления согласия.	Позволяет приложению читать электронную почту в почтовых ящиках пользователя.
AdminConsentDisplayName	Понятное имя, отображаемое для администраторов во время предоставления согласия.	Чтение почты пользователей
UserConsentDescription	Описание, отображаемое для пользователей во время предоставления согласия.	Позволяет приложению читать электронную почту в вашем почтовом ящике.
UserConsentDisplayName	Понятное имя, отображаемое для пользователей во время предоставления согласия.	Чтение почты
Value	Строка, используемая для идентификации разрешения во время выполнения авторизации OAuth 2.0. Value она также может объединяться со строкой URI идентификатора приложения, чтобы сформировать полное имя разрешения.	Mail.Read

Типы согласия

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

• Статическое согласие пользователя. Происходит автоматически во время выполнения авторизации OAuth 2.0, когда вы указываете ресурс, с которым ваше приложение будет взаимодействовать. В случае статического согласия пользователя ваше приложение должно уже содержать все необходимые разрешения в конфигурации приложения на портале Azure. Если пользователь (или администратор, если это необходимо) не предоставил согласия для этого приложения, Azure AD предложит пользователю дать согласие.

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

• Динамическое согласие пользователя. Представляет собой функцию модели приложения Azure AD версии 2. В этом случае приложение запрашивает набор разрешений, необходимых ему в потоке авторизации OAuth 2.0 для приложений версии 2. Пользователю будет предложено дать согласие, если он этого еще не сделал. Дополнительные сведения см. в разделе Добавочное и динамическое согласие.

  Важно!

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

• Согласие администратора. Это согласие необходимо, когда ваше приложение нуждается в доступе к определенным высокопривилегированным разрешениям. Согласие администратора гарантирует, что у администраторов есть дополнительные элементы управления, прежде чем разрешать приложениям или пользователям получать доступ к высокоприоритетным данным из организации. Дополнительные сведения см. в статье Использование конечной точки предоставления согласия администратора.

Рекомендации

Рекомендации по работе с клиентом

• Вашему приложению требуется только запрос на разрешения. Приложения с большим количеством разрешений в случае компрометации могут предоставить доступ к пользовательским данным.
• Выберите между делегированными разрешениями и разрешениями приложений на основе сценария, поддерживаемого вашим приложением.
  • Если вызов выполняется от имени пользователя, всегда используйте делегированные разрешения.
  • Если приложение не является интерактивным и не выполняет вызовы от имени какого-либо конкретного пользователя, тогда используйте только разрешения приложений. Разрешения приложениям являются высоко привилегированными и должны использоваться только при необходимости.
• При использовании приложения, основанного на конечной точке v2.0, всегда устанавливайте статические разрешения (те, которые указаны в регистрации вашего приложения), как расширенный набор динамических разрешений, которые запрашиваются во время выполнения (те, которые указаны в коде и отправлены в качестве параметров запроса в вашем запросе авторизации), чтобы сценарии, такие как согласие администратора, работали правильно.

Рекомендации по использованию ресурсов и API

• Ресурсы, которые предоставляют API, должны определять разрешения, которые специфичны для данных или действий, которые они защищают. Следование рекомендациям позволяет гарантировать, что клиенты не получат разрешения на доступ к данным, которые им не нужны, и что пользователи хорошо осведомлены о том, на использование каких данных они дают согласие.
• Ресурсы должны явным образом определять разрешения Read и ReadWrite (отдельно).
• Ресурсы должны отмечать любые разрешения, предоставляющие доступ к данным через границы пользователей, в качестве разрешений Admin.
• Ресурсы должны следовать шаблону именования Subject.Permission[.Modifier], где:

  • Subject соответствует доступному типу данных.

  • Permission соответствует действию, которое пользователь может применить к этим данным.

  • Modifier используется для описания специализаций другого разрешения.

    Пример:

  • Mail.Read позволяет пользователям читать письма электронной почты.

  • Mail.ReadWrite позволяет пользователям читать и писать письма.

  • Mail.ReadWrite.All предоставляет администратору или пользователю доступ ко всем письмам в организации.