Розвінчуємо OAuth 2.0 у Microsoft Graph: делеговані та застосункові дозволи

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

Раді вітати вас знову в нашому блозі! Якщо ви заглиблювались в автоматизацію Microsoft 365, то, швидше за все, вже натикались на обмеження, які накладають вбудовані конектори та традиційні скрипти. Складнощі автентифікації можуть ускладнити автоматизацію M365, особливо коли треба збалансувати надійний захист і безперешкодну роботу. Чи ви створюєте власні корпоративні застосунки, чи налаштовуєте ав

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, особливо коли треба збалансувати надійний захист із безперебійною функціональністю. Чи ви створюєте власні корпоративні застосунки, чи налаштовуєте автоматизовані фонові процеси, добре розуміти моделі автентифікації є критично важливим. Цей допис розбирає токени, області доступу та потоки надання згоди, щоб допомогти вам обрати правильну модель для завдань, орієнтованих на користувача, або для фонових завдань без участі користувача. Тож почнемо одразу та розберемося, як OAuth 2.0 забезпечує роботу Microsoft Graph API.

Знайомство з автентифікацією Microsoft Graph

Microsoft Graph — це єдиний шлюз до всієї екосистеми Microsoft 365. Замість того щоб працювати з окремими, роз'єднаними API для Exchange, SharePoint, Teams та Azure Active Directory (тепер Microsoft Entra ID), розробники й ІТ-адміністратори можуть отримувати доступ до всіх цих сервісів через одну кінцеву точку. Проте оскільки Graph керує доступом до чутливих корпоративних даних, захист цього шлюзу вимагає суворої системи автентифікації. Розуміння того, як ідентичність, токени доступу та дозволи взаємодіють між собою, — це перший крок до створення надійних і безпечних автоматизацій, які не зламаються під навантаженням і не викличуть сигналів тривоги в системах безпеки.

OAuth 2.0 у контексті Microsoft 365

В основі Microsoft Graph лежить протокол OAuth 2.0 для авторизації. Коли ваш застосунок або скрипт хоче звернутися до Graph, він не може просто передати облікові дані у відкритому вигляді. Натомість він має запросити токен доступу в платформи ідентичності Microsoft (Entra ID). Цей токен доступу працює як захищений цифровий паспорт. Він повідомляє Microsoft Graph, хто робить запит, який застосунок використовується і — що найважливіше — які конкретні дозволи (scopes) було надано цьому токену. Без дійсного токена Graph одразу відхилить запит із стандартною помилкою неавторизованого доступу.

Делеговані дозволи: коли діяти від імені користувача

Вибір правильної моделі дозволів повністю залежить від характеру вашого робочого навантаження. Делеговані дозволи призначені для застосунків, які працюють від імені авторизованого користувача. Коли застосунок використовує делеговані дозволи, він діє від імені користувача, який наразі ввійшов в систему. Якщо користувач запускає скрипт, щоб прочитати свій календар або оновити фото профілю, Graph оцінює запит не лише з огляду на те, що дозволено застосунку, а й на те, до чого має доступ сам користувач. Якщо користувач не має дозволу на перегляд певної поштової скриньки, делегований токен теж не надасть такого доступу. Ця модель ідеально підходить для застосунків з інтерфейсом для користувачів, інтерактивних інструментів і скриптів для особистої продуктивності.

Застосункові дозволи: фонові завдання без участі користувача

З іншого боку, що робити, коли потрібно запустити скрипт або службу опівночі, коли за клавіатурою нікого немає? Для фонових завдань без участі користувача, демон-служб і звітних інструментів на рівні клієнта потрібні застосункові дозволи. У цій моделі застосунок працює незалежно від будь-якого контексту користувача — він виконується під власною ідентичністю. Оскільки немає людини, яка могла б увійти в систему та інтерактивно надати згоду, застосункові дозволи потребують явного попереднього схвалення адміністратором клієнта. Після надання застосунок може отримувати дані по всій організації. Це робить модель надзвичайно потужною для адміністративної автоматизації, скриптів онбордингу та моніторингу відповідності, але водночас вимагає суворого контролю безпеки.

Області дії, токени та потоки надання згоди

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

Як уникнути «пекла» погодження адміністратором

Один із найпоширеніших «камінців спотикання» для розробників і адміністраторів — очікування адміністративного схвалення. Коли застосунок запитує привілейовані application scopes або чутливі delegated scopes, Microsoft Entra ID може вимагати, щоб адміністратор надав згоду застосунку, перш ніж можна буде видати будь-який токен. Якщо ваш конвеєр розгортання розраховує на те, що користувачі надають згоду самостійно, а політики клієнта раптово їх блокують, автоматизація повністю зупиняється. Щоб уникнути цього «пекла», завчасно складіть перелік потрібних дозволів, задокументуйте бізнес-обґрунтування та за потреби узгодьте з глобальними адміністраторами або адміністраторами застосунків попереднє налаштування згоди на рівні всього клієнта.

Типові пастки та як їх виправити

Навіть досвідчені розробники інколи стикаються з неприємними перешкодами авторизації під час роботи з Microsoft Graph. Розглянемо кілька типових проблем і способи їх вирішення:

Працює на моєму комп'ютері, не працює в інших: зазвичай спричинено відсутньою згодою або неправильними scopes. Виправлення: чітко задокументуйте потрібні scopes і за потреби налаштуйте згоду адміністратора на рівні всього клієнта.
Надмірне отримання великих обсягів даних: завантаження повних списків користувачів без фільтрації призводить до тайм-аутів і тротлінгу. Виправлення: використовуйте $select, $top, пагінацію та delta-запити.
Нескінченні цикли 401/403: спричинені простроченим токеном або використанням делегованого типу дозволу для фонової задачі без користувача. Виправлення: реалізуйте надійне оновлення токенів і перейдіть на application permissions для фонових завдань.
Досягнення лімітів частоти запитів: відповіді 429 означають, що ви надсилаєте запити занадто часто. Виправлення: реалізуйте експоненційну затримку (exponential backoff), враховуйте заголовок Retry-After і групуйте операції в пакети.
Розростання секретів: жорстко закодовані client secrets у скриптах — серйозний ризик безпеки. Виправлення: використовуйте Azure Key Vault, managed identities або безпечні змінні середовища.

Найкращі практики безпеки та управління

Коли ви відкриваєте доступ до свого клієнта Microsoft 365 через API, безпека має бути главним пріоритетом. Дотримуйтесь принципу найменших привілеїв: запитуйте лише абсолютний мінімум scopes, необхідних для роботи застосунку, і ніколи не запитуйте 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

Поширені запитання

Delegated чи Application — як вибрати?

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

Як уникнути тротлінгу?

Використовуйте $select, щоб обмежувати розмір корисного навантаження, реалізуйте пагінацію та delta-запити, за можливості групуйте запити в пакети, а скрипти завжди будуйте так, щоб коректно обробляти коди стану 429 із логікою повторних спроб.

Чи можна використовувати Graph без коду?

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

Чи достатньо безпечний Graph для звітів про відповідність вимогам?

Безумовно. За умови дотримання принципу найменших привілеїв, централізованого журналювання, аудитованих процесів надання згоди та безпечного керування секретами Microsoft Graph відповідає суворим корпоративним стандартам відповідності.

Висновок

Опанування автентифікації в Microsoft Graph – це ключ до максимальних можливостей для будь-якого адміністратора, архітектора чи розробника, який хоче справді використати потенціал Microsoft 365. Розуміючи критичну різницю між делегованими дозволами та дозволами застосунку, ретельно керуючи областями доступу та токенами й дотримуючись суворого управління безпекою, ви можете створювати автоматизацію, яка є одночасно потужною та безпечною. Щоб глибше зануритися в тему, переглянути приклади коду та вивчити просунуті стратегії обробки помилок і тротлінгу, обов’язково перегляньте відповідний епізод подкасту: Automate Microsoft 365 with Microsoft Graph API. Happy automating!