Чому самописна автентифікація та UX ламають відповідність вимогам у застосунках M365

By Mirko Peters · 2026-08-11

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

Titelbild: Why DIY Auth and UX Break Compliance in M365 Apps

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

Цю тему безпосередньо розвиває наш останній епізод подкасту Build Consistent M365 Apps with Microsoft Graph Toolkit. Обов’язково перегляньте повний епізод після читання цього посібника, щоб отримати аудіоогляд цих концепцій від початку до кінця!

Огляд

Більшість застосунків M365 ламаються на етапі автентифікації, пошуку в каталозі та роботи з календарем, і при цьому вони виглядають не у фірмовому стилі. Microsoft Graph Toolkit надає підтримувані React-компоненти з брендингом Microsoft, які під’єднуються до Graph, керують токенами та згодою, і одразу пропонують надійний, відповідний вимогам досвід, водночас дозволяючи безпечно налаштовувати інтерфейс.

Кому це допоможе

Фронтенд-розробникам і техлідам, які створюють застосунки, пов’язані з M365
Командам продуктів, яким потрібні швидкі та відповідні вимогам функції автентифікації й каталогу
Власникам безпеки та відповідності, яких втомили ризиковані самописні OAuth і розбіжності інтерфейсу

Чому самописне рішення ламається (і створює ризики для відповідності)

Коли розробники вирішують створювати власну автентифікацію та функції пошуку в каталозі самостійно, вони часто недооцінюють складність екосистеми ідентифікації Microsoft. Самописні рішення майже завжди несуть три основні категорії ризиків:

Дрейф OAuth: самописне підключення MSAL, зберігання токенів, оновлення та крайні випадки згоди, які непомітно відмовляють або залишають токени безпеки відкритими в локальному сховищі.
Невідповідність UX: шрифти, кольори, іконки та потоки, які не збігаються з Microsoft, що призводить до недовіри користувачів і плутанини під час запитів на вхід.
Прогалини в аудиті: неоднорідні екрани згоди, витік даних під час пошуку людей, що порушує внутрішнє управління даними, та слабкі показники доступності, які не проходять корпоративні перевірки відповідності.

Що дає Graph Toolkit

Замість того щоб будувати все з нуля, використання стандартизованої бібліотеки кардинально змінює ситуацію. Microsoft Graph Toolkit слугує мостом між вашим фронтенд-кодом і Microsoft Graph API, надаючи:

React-компоненти з брендингом Microsoft, які «просто працюють» із Graph без потреби в користувацьких обгортках API-клієнта.
Вбудовану автентифікацію та згоду (токени, оновлення, області дозволів) із MSAL всередині, керовану безпечно згідно з найкращими практиками Microsoft.
Кешування, обмеження частоти запитів і стани помилок, які обробляються за вас одразу з коробки.
Вигляд Fluent UI та доступність, зокрема навігацію з клавіатури, підтримку екранних читачів і макети для мов із написом справа наліво (RTL).
Безпечні точки налаштування (props, CSS-частини та класи) без порушення індикаторів відповідності, за якими користувачі перевіряють автентичність.

Основні компоненти, які знадобляться з першого дня

Коли ви впроваджуєте toolkit, ви одразу отримуєте доступ до багатої бібліотеки готових UI-віджетів. Кілька з них є абсолютно необхідними для будь-якого корпоративного застосунку:

Login: готовий вхід і вихід Microsoft, профіль, токени та потік згоди без громіздкого власного коду OAuth.
PeoplePicker: швидкий пошук у каталозі Azure AD із затримкою введення (debounce), з аватарами та можливістю множинного вибору; уникає пасток обмеження частоти запитів і пагінації, на які часто натрапляють самописні реалізації.
Agenda: події Outlook з близькими для M365 індикаторами (правила повторення, оновлення, часові пояси) та розумним кешуванням для оптимальної продуктивності.

Коли обрати Toolkit, а коли власний код

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

Швидкий старт (безбольовий шлях)

Створіть застосунок у Entra ID (Dev/Test/Prod), увімкніть MSAL і надайте дозволи Graph з мінімально необхідними правами.
Встановіть і підключіть провайдер у React (провайдер MSAL і провайдер Graph Toolkit).
Видаліть компоненти: <Login />, <PeoplePicker />, <Agenda />.
Задайте дозволи для кожної сторінки (наприклад, User.Read, Calendars.Read, People.Read) і перевірте вимоги щодо згоди.
Безпечно змінюйте оформлення: застосовуйте теми-токени та CSS-частини, зберігаючи шаблони Microsoft без змін.
Запустіть пілотну версію для невеликої групи користувачів, зберіть відгуки щодо зручності та продуктивності, а потім розширте впровадження.

Контрольний список для продакшну (безпека та надійність)

Перш ніж запускати застосунок у продакшн, пройдіться цим ґрунтовним списком, щоб переконатися, що реалізація залишається безпечною та надійною під корпоративними навантаженнями:

Мінімальні дозволи; ретельно розділіть делеговані дозволи користувача та дозволи застосунку.
Безпечне зберігання секретів і сертифікатів (за можливості з використанням Azure Key Vault).
Термін дії токенів і логіка повторів: перевірте потоки оновлення та реалізуйте експоненційну затримку при помилках 429 або 503.
Умовний доступ: протестуйте багатофакторну автентифікацію та політики відповідності пристроїв разом із потоками вашого тулкіту.
Телеметрія: журналюйте ідентифікатори запитів, метрики затримки, влучання в кеш і помилки Graph API для ефективного моніторингу.
Перевірка доступності: перевірте навігацію клавіатурою, структурні орієнтири та контрастність кольорів.
Перевірка бренду: переконайтеся, що стилізація Fluent UI і ваша власна брендова оболонка залишаються візуально узгодженими.

Нотатки щодо продуктивності

Продуктивність може вирішити, чи прийматимуть користувачі застосунок. На щастя, компоненти створені з урахуванням оптимізації. Вони використовують ліниве завантаження даних і клієнтське кешування, щоб інтерфейс лишався швидким. Уникайте викликів API за схемою N+1, покладаючись на вбудовані списки тулкіту, і обов’язково групуйте пошук користувачів у пакети, коли збагачуєте результати пошуку або гортаєте довгі списки.

Налаштування без втрати довіри

Розробники часто переживають, що готові компоненти обмежують можливості брендування застосунку. Однак ви легко можете налаштувати вигляд, не жертвуючи безпекою. Використовуйте наявні властивості (наприклад, діапазони дат і фільтри запитів) замість форку коду. Оформлюйте застосунок за допомогою токенів Fluent і CSS-змінних, і завжди зберігайте впізнавані для користувачів базові шаблони Microsoft, як-от діалоги входу та згоди.

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

«Працює локально, не працює в продакшні» → Зазвичай причина в невідповідності URI перенаправлення або дозволів. Перевірте параметри реєстрації вашого застосунку в Azure Entra ID.
Пошук людей порожній → Відсутні дозволи People.Read або User.ReadBasic.All чи надто обмежувальні налаштування каталогу у вашому клієнті.
Порожній календар подій → Не надано згоду на дозвіл Calendars.Read або запитується поштова скринька непідтримуваного типу.
Нескінченні запити входу → Заблоковано сторонні cookie або надто жорсткі обмеження сеансу в умовному доступі. Протестуйте у приватному вікні та перегляньте свої політики CA.

Ідеї KPI для підтвердження ефекту

Щоб обґрунтувати цей архітектурний перехід перед керівництвом інженерного напрямку, відстежуйте такі метрики: час до першої функції (створення автентифікації, календаря та вибору людей до і після переходу на тулкіт), кількість збоїв автентифікації та звернень до служби підтримки на тисячу користувачів, час до повної інтерактивності сторінок календаря та людей, кількість знайдених проблем доступності в кожному релізі та зауваження з відповідності, зафіксовані під час перевірок безпеки.

Шлях міграції (спершу замініть ризикові власні елементи)

Замініть власну обробку OAuth на стандартний компонент Login.
Замініть індивідуальні, неоптимізовані пошуки в каталозі компонентом PeoplePicker.
Замініть власні віджети календаря компонентом Agenda.
Додавайте допоміжні функції, як-от Files, Tasks і Presence, відповідно до потреб вашої дорожньої карти продукту.

Головне

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

Готові глибше зануритися в створення надійних і відповідних вимогам застосунків для Microsoft 365? Перейдіть до подкасту та послухайте повний епізод: Build Consistent M365 Apps with Microsoft Graph Toolkit!