2025-08-11

Дозволи та моделі згоди в Microsoft Graph пояснено

Більшість застосунків на базі Graph зазнають невдачі під час впровадження не через код, а через згоду. У тестових тенантах дозволено широке тестування, а у продуктивному середовищі політики суворі й блокують ризиковані області доступу. Виправлення полягає в розумінні двох моделей Graph: делегованої (від імені користувача) та додаткової (застосунок без користувача, на рівні організації), а також у запитах мінімально необхідних областей доступу, що відповідають реальній роботі застосунку. Де можливо, зберігайте дані користувачів у делегованій моделі; додаткову, без участі користувача, модель використовуйте для фонових або міжтенантних завдань і заздалегідь плануйте схвалення адміністратором. Рано вивчіть політики згоди тенанта, поетапно надавайте дозволи (від пілотного запуску до розширення) і документуйте, навіщо потрібна кожна область доступу. Використовуйте альтернативи з принципом найменших привілеїв, наприклад Calendars.Read замість Calendars.ReadWrite або Team.ReadBasic.All замість повного доступу до каталогу. Доповнюйте це управлінням: процесом попереднього схвалення, щоквартальними переглядами, тегуванням і журналами аудиту. Результат: менше спливаючих вікон «потрібне схвалення адміністратора», швидше погодження з боку безпеки та впровадження, яке витримує перевірку часом.

Apple Podcasts · Spotify · YouTube

Microsoft Graph Permissions and Consent Models Explained (English)