Разбираемся с OAuth 2.0 в Microsoft Graph: делегированные и application-разрешения

By Mirko Peters · 2026-08-11 · Updated 2026-08-28

Automatically translated with AI from the original post. Read the English original

Titelbild: Demystifying OAuth 2.0 in Microsoft Graph: Delegated vs. Application Permissions

Добро пожаловать обратно в блог! Если вы глубоко погрузились в автоматизацию Microsoft 365, то наверняка натыкались на ограничения, которые накладывают встроенные коннекторы и традиционные возможности скриптов. Разобраться в сложностях аутентификации бывает непросто, особенно когда нужно автоматизировать M365 и при этом сохранить надёжную безопасность и бесперебойную работу. Создаёте ли вы собственные корпоративные приложения или настраиваете фоновые автоматизированные процессы, твёрдое понимание моделей аутентификации критически важно. В этой статье мы разберём токены, области доступа (scopes) и потоки согласия, чтобы помочь вам выбрать подходящую модель для пользовательских или фоновых задач без участия человека. Давайте сразу разберёмся, как OAuth 2.0 работает в Microsoft Graph API.

Введение в аутентификацию Microsoft Graph

Microsoft Graph — это единая точка входа ко всей экосистеме Microsoft 365. Вместо того чтобы работать с разрозненными API для Exchange, SharePoint, Teams и Azure Active Directory (ныне Microsoft Entra ID), разработчики и ИT-администраторы могут обращаться ко всем этим сервисам через одну конечную точку. Однако, поскольку Graph контролирует доступ к конфиденциальным корпоративным данным, защита этого шлюза требует строгой системы аутентификации. Понимание того, как связаны удостоверение, токены доступа и разрешения, — первый шаг к созданию надёжных автоматизаций, которые не сломаются под нагрузкой и не вызовут сигналов тревоги в системах безопасности.

Понимание OAuth 2.0 в контексте Microsoft 365

По своей сути Microsoft Graph опирается на протокол OAuth 2.0 для авторизации. Когда ваше приложение или скрипт хочет обратиться к Graph, он не может просто отправить учётные данные в открытом виде. Вместо этого он должен запросить токен доступа у платформы удостоверений Microsoft (Entra ID). Этот токен доступа действует как защищённый цифровой паспорт. Он сообщает Microsoft Graph, кто делает запрос, какое приложение используется и, что самое важное, какие конкретные разрешения (scopes) были выданы этому токену. Без действительного токена Graph немедленно отклонит запрос со стандартной ошибкой неавторизованного доступа.

Делегированные разрешения: когда действовать от имени пользователя

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

Application-разрешения: автоматизация фоновых задач без участия пользователя

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

Работа с областями доступа, токенами и потоками согласия

Словарь аутентификации и авторизации иногда может показаться перегруженным, но если разбить процесс на этапы, всё становится понятнее. Области доступа (scopes) — это конкретные разрешения, которые запрашивает ваше приложение, например User.Read.All или Mail.Read. Когда пользователь или администратор авторизует приложение, он проверяет эти области доступа и одобряет их. После одобрения платформа удостоверений выдаёт JSON Web Token (JWT). Ваш код добавляет этот токен в заголовок HTTP Authorization для каждого запроса к Microsoft Graph. Правильное управление согласием гарантирует, что приложение сможет получать эти токены без неожиданных препятствий.

Как не застрять в ожидании согласия администратора

Одна из самых распространённых проблем, с которыми сталкиваются разработчики и администраторы, — ожидание одобрения администратора. Когда приложение запрашивает высокопривилегированные области доступа для приложений или чувствительные делегированные области доступа, Microsoft Entra ID может потребовать, чтобы администратор дал согласие на приложение, прежде чем будут выданы какие-либо токены. Если ваш конвейер развёртывания рассчитывает на то, что пользователи могут дать согласие самостоятельно, а политики клиента внезапно их блокируют, автоматизация полностью останавливается. Чтобы избежать ожидания согласия администратора, заранее составьте карту необходимых разрешений, задокументируйте бизнес-обоснование и согласуйте с глобальными администраторами или администраторами приложений предварительную настройку согласия на уровне всего клиента там, где это необходимо.

Частые ошибки и способы их исправления

Даже опытные разработчики время от времени сталкиваются с неприятными препятствиями авторизации при работе с Microsoft Graph. Рассмотрим несколько типичных проблем и способы их решения:

Работает у меня, не работает у других: обычно вызвано отсутствующим согласием или неверными областями доступа. Решение: чётко задокументируйте необходимые области доступа и при необходимости настройте согласие администратора на уровне всего клиента.
Загрузка огромных объёмов данных: получение полных списков пользователей без фильтрации приводит к тайм-аутам и ограничению частоты запросов. Решение: используйте $select, $top, постраничную навигацию и delta-запросы.
Бесконечные циклы 401/403: вызваны истёкшим токеном или использованием делегированного разрешения для задачи без участия пользователя. Решение: реализуйте надёжное обновление токенов и переключитесь на разрешения приложения для фоновых задач.
Превышение лимитов запросов: ответы 429 означают, что вы отправляете запросы слишком часто. Решение: реализуйте экспоненциальную задержку повторов, учитывайте заголовок Retry-After и объединяйте операции в пакеты.
Распространение секретов: жёстко заданные в скриптах client secrets представляют серьёзный риск для безопасности. Решение: используйте Azure Key Vault, управляемые удостоверения или защищённые переменные среды.

Лучшие практики безопасности и управления

Открывая доступ к своему клиенту Microsoft 365 через API, безопасность必须 должна быть главным приоритетом. Следуя принципу наименьших привилегий, запрашивайте только абсолютно минимальный набор областей доступа, необходимых для работы приложения, — никогда не запрашивайте Directory.AccessAsUser.All только ради чтения отображаемого имени пользователя. Ведите понятный реестр согласий с указанием того, какие приложения имеют доступ к вашему клиенту, полностью изолируйте регистрации приложений для разработки, тестирования и производства и установите строгий график ротации client secrets и сертификатов.

Ваши первые реальные запросы (примеры)

Когда модель аутентификации настроена, можно начинать выполнять запросы к Graph API. Вот несколько практичных примеров, которые можно адаптировать:

Новые сотрудники с определённой даты:
GET /users?$filter=createdDateTime ge 2025-10-01T00:00:00Z&$select=id,displayName,mail,department
Мои ближайшие собрания:
GET /me/events?$top=10&$select=subject,start,end,organizer,webLink
Участники группы:
GET /groups/{group-id}/members?$select=id,displayName,mail
Изменённые пользователи (delta):
GET /users/delta?$select=id,displayName,mail

Часто задаваемые вопросы

Делегированные или Application — как выбрать?

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

Как избежать ограничения частоты запросов (throttling)?

Используйте $select, чтобы ограничивать размер полезной нагрузки, реализуйте постраничную выборку и delta-запросы, по возможности объединяйте запросы в пакеты, а свои скрипты всегда строьте так, чтобы они корректно обрабатывали коды состояния 429, с логикой повторных попыток.

Можно ли использовать Graph без программирования?

Да! Вы можете прототипировать конечные точки в Graph Explorer и оркестрировать рабочие процессы с помощью Power Automate. Для сложной логики переходите к официальным SDK или скриптам PowerShell.

Достаточно ли безопасен Graph для отчётов о соответствии требованиям?

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

Заключение

Освоение аутентификации в Microsoft Graph — это ключ к полному использованию возможностей Microsoft 365 для любого администратора, архитектора или разработчика. Понимая принципиальное различие между делегированными разрешениями и разрешениями приложения, грамотно управляя областями доступа и токенами и соблюдая строгие правила безопасности, вы сможете создавать автоматизацию, которая одновременно мощная и безопасная. Чтобы глубже разобраться в теме, изучить примеры кода и узнать продвинутые стратегии обработки ошибок и throttling, обязательно посмотрите связанный выпуск подкаста: Automate Microsoft 365 with Microsoft Graph API. Удачной автоматизации!