Общие сведения о делегированных доступах

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

Почему следует использовать делегированный доступ?

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

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

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

Запрос областей в качестве клиентского приложения

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

После запроса области приложением пользователю или администратору потребуется предоставить запрошенный доступ. Пользователи потребителей с учетными записями Майкрософт, такие как Outlook.com или учетные записи Xbox Live, всегда могут предоставлять области для себя. Пользователи организации с учетными записями Microsoft Entra могут или не могут предоставлять области в зависимости от параметров организации. Если пользователь организации не может напрямую согласиться с областями, он должен попросить администратора организации предоставить им согласие.

Всегда следуйте принципу наименьшей привилегии: никогда не следует запрашивать области, необходимые приложению. Этот принцип помогает ограничить риск безопасности, если приложение скомпрометировано и упрощает предоставление администраторам доступа к приложению. Например, если вашему приложению нужно только вывести список чатов, к которому принадлежит пользователь, но не нужно показывать сообщения чата самостоятельно, следует запросить более ограниченную область Microsoft Graph Chat.ReadBasic вместо Chat.Read. Дополнительные сведения о областях openID см. в разделе "Области OpenID".

Проектирование и публикация областей для службы ресурсов

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

Маркер для самостоятельного выполнения

В сценарии, в котором:

• Приложение ресурсов и клиентское приложение одинаковы.
• У приложения нет зарегистрированного веб-API.
• Приложение запрашивает маркер для делегированного разрешения, которое он предоставляет сам.

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

Как работает делегированный доступ?

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

• Авторизация клиентских приложений. Клиентские приложения авторизованы путем предоставления областей. Если клиентское приложение предоставляет область пользователю или администратору для доступа к некоторым ресурсам, это предоставление будет записано в идентификаторе Microsoft Entra. Все маркеры делегированного доступа, запрашиваемые клиентом для доступа к ресурсу от имени соответствующего пользователя, будут содержать значения утверждений этих областей в утверждении scp . Приложение ресурсов проверяет это утверждение, чтобы определить, предоставлена ли клиентскому приложению правильная область вызова.
• Авторизация пользователей . Пользователи авторизованы с помощью вызываемого ресурса. Приложения ресурсов могут использовать одну или несколько систем для авторизации пользователей, таких как управление доступом на основе ролей, отношения владения и членства, списки управления доступом или другие проверки. Например, идентификатор Microsoft Entra проверяет, назначен ли пользователь роли управления приложениями или общей роли администратора, прежде чем разрешать им удалять приложения организации, но также позволяет всем пользователям удалять приложения, принадлежащие им. Аналогичным образом служба SharePoint Online проверяет, что у пользователя есть соответствующие права владельца или читателя над файлом, прежде чем разрешить этому пользователю открыть его.

Пример делегированного доступа — OneDrive с помощью Microsoft Graph

Рассмотрим следующий пример:

Алиса хочет использовать клиентское приложение для открытия файла, защищенного API ресурсов Microsoft Graph. Для авторизации пользователей служба OneDrive проверяет, хранится ли файл на диске Алисы. Если он хранится на диске другого пользователя, OneDrive отклонит запрос Алисы как несанкционированный, так как Алиса не имеет права читать диски других пользователей.

Для авторизации клиентского приложения OneDrive проверяет, предоставлена Files.Read ли клиенту область от имени вошедшего пользователя. В этом случае вошедшего пользователя является Алиса. Если Files.Read приложение для Алисы не предоставлено, OneDrive также завершится сбоем запроса.

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

См. также

• Открытие областей подключения
• Роли RBAC
• Общие сведения о разрешениях в Microsoft Graph
• Справочник по разрешениям Microsoft Graph