Опановуємо OAuth 2.0 та API-ключі в користувацьких конекторах Power Apps

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

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

Titelbild: Mastering OAuth 2.0 and API Keys in Power Apps Custom Connectors

Під час створення корпоративних рішень на Microsoft Power Platform розробники часто натрапляють на структурну межу. Вбудовані конектори чудово працюють зі стандартними службами Microsoft 365, компонентами Azure та популярними сторонніми SaaS-платформами. Але щойно вашому застосунку потрібні спеціалізовані дані лінійного бізнесу, інтеграція з застарілим бекендом або власні галузеві API, стандартні інструменти закінчуються саме там, де починаються ваші реальні бізнес-дані. Саме тут у пригоді стають користувацькі конектори: вони працюють як універсальний адаптер, який навчає Power Apps і Power Automate напряму взаємодіяти з вашими унікальними API.

Проте створити користувацький конектор — це лише половина справи. Справжнім відрізненням між крихким прототипом і стійкою корпоративною інтеграцією є безпечна автентифікація. Якщо ви неправильно налаштуєте OAuth 2.0 або неналежно керуватимете API-ключами, ваші застосунки матимуть збої згоди кількох користувачів, несподівані тайм-аути токенів і вразливості безпеки. У цьому грунтовному посібнику ми розберемо, як налаштувати безпечну автентифікацію для ваших користувацьких конекторів: від призначення областей дій за принципом найменших привілеїв до плавного оновлення токенів і захисту ваших продуктивних середовищ.

Вступ до користувацьких конекторів і безпечної автентифікації

По суті, користувацький конектор є обгорткою навколо RESTful API, яка дає змогу Power Apps, Power Automate та Azure Logic Apps взаємодіяти із зовнішніми службами за допомогою дій, тригерів і типізованих схем. Але перш ніж дані почнуть рухатися, потрібно встановити довіру. Автентифікація — це абсолютно перша перешкода, яку необхідно подолати. Чи використовуєте ви API-ключі, базову автентифікацію чи золотий стандарт — OAuth 2.0, правильно налаштований потік безпеки з самого початку визначає загальну працездатність і прийняття вашого застосунку.

Розробники часто поспішають із налаштуванням безпеки, аби лише швидко отримати успішне отримання даних, і лише згодом з'ясовується, що обраний метод автентифікації не витримує розгортання для ширшого кола користувачів. Захист вашого користувацького конектора означає розуміння точних протоколів рукостискання, яких вимагає цільовий API, і коректне відображення їх у структурі безпеки Power Platform.

Анатомія користувацьких конекторів Power Apps

Щоб опанувати автентифікацію, спочатку потрібно зрозуміти базову структуру користувацького конектора. Добре спроєктований конектор складається з кількох ключових компонентів:

Хост і базова URL-адреса: кінцеві точки, на які спрямовується трафік вашого API. HTTPS є строго обов'язковим.
Параметри безпеки: механізм, який підтверджує, хто викликає API. Він може бути простим, як API-ключ, або складним, як надання коду авторизації OAuth 2.0.
Визначення: дії (методи, шляхи, параметри запиту, заголовки та корисні навантаження запитів і відповідей) і тригери, що визначають доступні операції.
Код (необов'язково): політики-скрипти на C#, які використовуються для перезапису URL-адрес, встановлення певних заголовків або перетворення невеликих корисних навантажень на льоту.

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

Опановуємо налаштування OAuth 2.0 і API-ключів

Вибір правильного типу автентифікації повністю залежить від того, що підтримує ваш базовий API. Щоразу, коли це можливо, віддавайте перевагу OAuth 2.0. Він забезпечує безпечне делегування на основі токенів без розкриття облікових даних користувача. Налаштовуючи OAuth 2.0 у майстрі користувацького конектора Power Apps, потрібно вказати такі параметри:

Постачальник ідентифікації: служба, яка видає ваші токени (наприклад, Azure Active Directory, Auth0, Okta або власний сервер ідентифікації).
Client ID і Client Secret: унікальні ідентифікатори вашого зареєстрованого застосунку.
URL-адреса авторизації та URL-адреса токена: кінцеві точки, які відповідають за запит входу користувача та обмін кодів авторизації на токени доступу.
Redirect URL: URL-адреса зворотного виклику, яку генерує Power Apps і яку потрібно зареєструвати в налаштуваннях вашого постачальника ідентифікації.

У сценаріях, де OAuth 2.0 занадто складний або не підтримується цільовою системою, можна використати API-ключ. API-ключі зазвичай передаються через HTTP-заголовки (наприклад, Ocp-Apim-Subscription-Key або Authorization) або через рядок запиту. Їх простіше реалізувати, але вони потребують суворого управління секретами, щоб запобігти витоку.

Налаштування областей доступу з мінімальними привілеями та оновлення токенів

Типова антипатерн у розробці власних конекторів — запит широких дозволів з високими привілеями лише для того, щоб швидко все запрацювало. Це призводить до серйозного дрейфу безпеки. Натомість налаштування автентифікації слід будувати на областях доступу з мінімальними привілеями.

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

Уникнення типових пасток: згода кількох користувачів і тайм-аути токенів

Чи доводилося вам створювати конектор, який ідеально працював для вас як для розробника, але повністю ламався, щойно колега намагався ним скористатися? Це класична проблема згоди кількох користувачів. Зазвичай вона виникає через відсутні області OAuth, неналаштовану реєстрацію багатоорендного застосунку або невідповідність URI перенаправлення. Щоб її виправити, перевірте, чи реєстрація застосунку дозволяє згоду кількох користувачів, і чи URL перенаправлення конектора явно внесено до дозволених у вашому постачальнику ідентифікації.

Ще один поширений головний біль — тайм-аути токенів. Якщо ваш API видає короткоживучі токени, а конектор не запитує або не обробляє токен оновлення, застосунок непередбачувано розриватиме з'єднання. Завжди тестуйте конектор в умовах, коли токени природно спливають, щоб переконатися, що процес оновлення виконується прозоро.

Тестування та перевірка потоку автентифікації

Дисциплінована методологія тестування заощаджує години усунення несправностей. Ніколи не тестуйте автентифікацію безпосередньо в Power Apps під час першої спроби. Натомість дотримуйтеся структурованої послідовності:

Спочатку перевірте кінцеві точки, заголовки та обмін токенами в Postman. Збережіть робочі приклади.
Імпортуйте робочі параметри до майстра власного конектора.
Використайте вбудовану вкладку Test на порталі власних конекторів Power Apps, щоб виконати тестові виклики для кожної дії та перевірити, чи успішно завершуються кроки автентифікації.
Наостанок інтегруйте конектор у свій застосунок Power Apps або потік Power Automate та перевірте поведінку від початку до кінця.

Виробничі обмеження, зіставлення помилок і обмеження частоти запитів

Перенесення власного конектора із середовища розробки у виробниче потребує посилення захисту. Необроблені коди помилок, які повертає сторонній API (як-от незрозумілі помилки 500 internal server error або повідомлення 403 forbidden), плутають кінцевих користувачів. Реалізуйте зіставлення помилок у політиках конектора, щоб перетворювати коди статусу 4xx і 5xx на зрозумілі повідомлення разом з ідентифікаторами кореляції для служб підтримки.

Стійкість не менш важлива. API часто встановлюють суворі ліміти частоти запитів. Якщо погано спроєктований цикл у Power Automate надто швидко звертається до кінцевої точки, ви спровокуєте помилки обмеження HTTP 429. Реалізуйте політики повторних спроб з експоненційною затримкою та використовуйте кешування там, де це доречно, щоб дотримуватися серверних лімітів і зберігати стабільність застосунку.

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

Корпоративне управління гарантує, що власні конектори не стануть каналом тіньової ІТ-інфраструктури. Щоб підтримувати безпечний стан, дотримуйтеся таких основних вимог управління:

Зберігання секретів: Ніколи не вбудовуйте клієнтські секрети або ключі API безпосередньо у визначення конекторів. Зберігайте їх безпечно в Azure Key Vault або використовуйте змінні середовища.
Політики DLP: Застосовуйте політики запобігання втраті даних (DLP), які класифікують конектори як Business або Non-Business, щоб контролювати, де і як ваш власний конектор можна використовувати в різних середовищах.
Керовані ідентичності: Використовуйте керовані ідентичності абоservice principal для сценаріїв «сервер–сервер» і фонової автоматизації, де контекст користувача не потрібен.
Розділення середовищ: підтримуйте окремі з'єднувачі для розробки, тестування та робочого середовища з різними обліковими даними, і суворо обмежуйте коло осіб, які мають дозвіл публікувати оновлення в робочому середовищі.

Висновки та головне

Опанування автентифікації для власних з'єднувачів Power Apps перетворює ваші low-code рішення з ізольованих застосунків на глибоко інтегровані потужні корпоративні інструменти. Розуміючи будову з'єднувачів, налаштовуючи надійні потоки OAuth 2.0, застосовуючи області доступу з найменшими привілеями та встановлюючи захисні бар'єри для робочого середовища, ви гарантуєте, що ваші інтеграції залишатимуться безпечними, масштабованими та стійкими в часі.

Щоб глибше зануритися в тему та послухати думки експертів про побудову надійних інтеграцій, формування корисних навантажень і складні етапи автентифікації, обов'язково перегляньте відповідний епізод подкасту: Build Secure Custom Connectors for Power Apps. Успішної розробки!