Сведения о разрешениях и согласии на платформе удостоверений Майкрософт

  • Статья

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

Сценарии доступа

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

Image shows illustration of access scenarios.

Делегированный доступ (доступ от имени пользователя)

В этом сценарии доступа пользователь вошел в клиентское приложение. Клиентское приложение обращается к ресурсу от имени пользователя. Для делегированного доступа требуются делегированные разрешения. Клиент и пользователь должны быть авторизованы отдельно для выполнения запроса. Дополнительные сведения о сценарии делегированного доступа см . в сценарии делегированного доступа.

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

Для пользователя авторизация зависит от привилегий, предоставленных пользователю для доступа к ресурсу. Например, пользователь может быть авторизован для доступа к ресурсам каталога с помощью управления доступом на основе ролей Microsoft Entra (RBAC) или доступа к ресурсам почты и календаря с помощью Exchange Online RBAC. Дополнительные сведения о RBAC для приложений см. в разделе RBAC для приложений.

Доступ только для приложений (доступ без пользователя)

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

Доступ только для приложений использует роли приложения вместо делегированных область. При предоставлении согласия роли приложений также могут называться разрешениями приложений. Клиентское приложение должно быть предоставлено соответствующим разрешениям приложения для вызываемого приложения ресурсов. После предоставления клиентское приложение может получить доступ к запрошенным данным. Дополнительные сведения о назначении ролей приложений клиентским приложениям см. в разделе "Назначение ролей приложения приложения".

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

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

Например, примите приложение, которое было предоставлено Files.Read.All делегированное разрешение от имени пользователя. Приложение сможет считывать только файлы, к которым пользователь может получить личный доступ.

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

Например, приложение, предоставленное приложению Files.Read.All API Microsoft Graph, сможет прочитать любой файл в клиенте с помощью Microsoft Graph. Как правило, только администратор или владелец субъекта-службы API может предоставить разрешения приложений, предоставляемые этим API.

Сравнение делегированных и разрешений приложений

Типы разрешений Делегированные разрешения Разрешения приложения
Типы приложений Веб- или мобильное приложение / одностраничные приложения (SPA) Веб-приложение или управляющая программа
Контекст доступа Получение доступа от имени пользователя Получение доступа без пользователя
Кто может давать согласие — пользователи могут предоставить согласие на получение данных
— Администратор могут предоставить согласие для всех пользователей.		 Предоставить согласие может только администратор
Методы согласия — Статический: настроенный список при регистрации приложения
— Dynamic: запрос отдельных разрешений при входе		 — Статический ТОЛЬКО: настроенный список при регистрации приложения
Другие названия -Области
— область разрешений OAuth2		 — роли приложения
— Разрешения только для приложений
Результат согласия (специфичный для Microsoft Graph) OAuth2PermissionGrant appRoleAssignment

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

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

Основные сведения о запросе согласия — это список разрешений, необходимых приложению, и сведения о издателе. Дополнительные сведения о запросе согласия и опыте предоставления согласия для администраторов и конечных пользователей см. в статье об опыте предоставления согласия приложений.

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

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

Администраторы могут предоставить согласие для себя или всей организации. Дополнительные сведения о согласии пользователей и администраторов см . в обзоре согласия пользователя и администратора.

Запросы проверки подлинности запрашиваются для согласия администратора, если согласие не было предоставлено, и если запрашивается одно из этих разрешений с высоким уровнем привилегий.

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

Предварительная авторизация

Предварительная авторизация позволяет владельцу приложения ресурсов предоставлять разрешения, не требуя, чтобы пользователи видели запрос согласия для того же набора разрешений, которые были предварительно авторизованы. Таким образом, приложение, которое не было предварительно авторизовано, не запрашивает у пользователей согласие на разрешения. Владельцы ресурсов могут предварительно авторизовывать клиентские приложения на портале Azure или с помощью PowerShell и API, таких как Microsoft Graph.

См. также