Автентифікація (підготовча версія)

Стаття
05/30/2023

У цій статті наведено огляд Microsoft Entra налаштувань для виклику Power Platform API (попередній перегляд). Щоб отримати доступ до ресурсів, доступних через Power Platform API, ви повинні отримати токен на Microsoft Entra пред’явника та надіслати його у вигляді заголовка разом із кожним запитом. Залежно від типу ідентифікації, який ви підтримуєте (користувач чи принципал послуги), існують різні потоки для отримання цього токена на пред’явника, як описано в цій статті.

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

Створіть заявку, зареєстровану у вашому Microsoft Entra орендарі
Налаштування дозволів API
Налаштування загальнодоступного клієнта (необов’язково)
Налаштування сертифікатів і секретів (необов’язково)
Запит маркера доступу

Крок 1. Створення реєстрації програми

Перейдіть на Microsoft Entra сторінку реєстрації в додатку та створіть нову реєстрацію. Задайте ім’я програми та переконайтеся, що вибрано пункт Один клієнт. Настроювання URI переспрямування можна пропустити.

Крок 2. Налаштування дозволів API

У новій реєстрації перейдіть до вкладки Керування — дозволи API. У розділі Налаштування дозволів виберіть Додати дозвіл. У діалоговому вікні, що відкриється, виберіть API, що використовує моя організація і виконайте пошук для API Power Platform. Можна переглянути кілька записів з іменем, подібним до цього, тому слід використовувати один із GUID 8578e004-a5c6-46e7-913e-12f58912df43.

Якщо під час пошуку за допомогою GUID API не відображається Power Platform в списку, можливо, у вас все ще є доступ до нього, але видимість не оновлюється. Для примусового оновлення виконайте наведений нижче сценарій PowerShell.

#Install the Microsoft Entra the module
Install-Module AzureAD

Connect-AzureAD
New-AzureADServicePrincipal -AppId 8578e004-a5c6-46e7-913e-12f58912df43 -DisplayName "Power Platform API"

Тут необхідно вибрати потрібні вам дозволи. Вони згруповані за просторами імен. У просторі імен ви побачите типи ресурсів і дії, наприклад AppManagement.ApplicationPackages.Read , які надають дозволи на читання для пакетів додатків. Щоб дізнатися більше, перегляньте нашу довідкову статтю про дозволи.

Нотатка

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

Для посвідчень принципалів служби дозволи програми не використовуються. Натомість принципали служби наразі розглядаються як адміністратори Power Platform і повинні бути зареєстровані сценарієм PowerShell — створення принципала служби.

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

Крок 3. Налаштування загальнодоступного клієнта (необов’язково)

Якщо ваш додаток вимагає читання та написання ресурсів від імені користувача, увімкніть налаштування Загальнодоступний клієнт. Це єдиний спосіб, за Microsoft Entra допомогою якого ID приймає властивості імені користувача та пароля в тілі вашого запиту токена. Також зверніть увагу, що якщо ви плануєте використовувати цю функцію, вона не працюватиме для облікових записів, у яких увімкнено багатофакторну автентифікацію.

Для увімкнення перейдіть на вкладку Керування — автентифікація. У розділі Додаткові параметри установіть для параметра Загальнодоступний клієнт значення Так.

Крок 4. Налаштування сертифікатів і секретів (необов’язково)

Якщо ваш застосунок потребує читання та запису ресурсів від самого себе, також відомого як принципал служби, є два способи автентифікації. Щоб використовувати сертифікати, перейдіть на вкладку Керування — сертифікати та секретні ключі. У розділі Сертифікати завантажте сертифікат x509, який можна використовувати для автентифікації. Інший спосіб зробити це — за допомогою розділу Секрети можна створити секрет клієнта. Збережіть секретний ключ у безпечному місці для використання для потреб автоматизації. За допомогою сертифіката або секретних параметрів ви можете автентифікуватися за допомогою Microsoft Entra цього клієнта та отримати для нього токен, який ви передасте командлетам REST API або командлетам PowerShell.

Крок 5. Запит маркера доступу

Існує два способи отримання маркера носія для доступу. Один — для імені користувача й пароля, а інший — для принципалів служб.

Цикл для імені користувача та пароля

Обов’язково прочитайте розділ «Загальнодоступний клієнт» вище. Потім надішліть запит POST через HTTP to Microsoft Entra ID з набором корисних даних імені користувача та пароля.

Content-Type: application/x-www-form-urlencoded
Host: login.microsoftonline.com
Accept: application/json
POST https://login.microsoftonline.com/YOUR_TENANT.COM/oauth2/v2.0/token
BODY:
client_id={CLIENT_ID_FROM_AZURE_CLIENT_APP}&scope=https://api.powerplatform.com/.default&username={USER_EMAIL_ADDRESS}&password={PASSWORD}&grant_type=password

Наведений вище приклад містить заповнювачі, які ви можете отримати з клієнтської програми в Microsoft Entra ID. Ви отримуєте відповідь, яку можна використовувати для подальших викликів API Power Platform .

{
  "token_type": "Bearer",
  "scope": "https://api.powerplatform.com/AppManagement.ApplicationPackages.Install https://api.powerplatform.com/AppManagement.ApplicationPackages.Read https://api.powerplatform.com/.default",
  "expires_in": 4747,
  "ext_expires_in": 4747,
  "access_token": "eyJ0eXAiOiJKV1QiLCJu..."
}

Використовуйте значення access_token у наступних викликах Power Platform API у заголовку HTTP Авторизація.

Основний потік послуг

Обов’язково прочитайте розділ «Сертифікати та секрети» вище. Потім надішліть запит POST через HTTP to Microsoft Entra ID із секретним корисним навантаженням клієнта. Це часто називають автентифікацією принципала служби.

Важливо

Цим можна скористатися лише після того, як ви зареєстрували цей ідентифікатор клієнтської програми за допомогою Microsoft Power Platform відповідної документації PowerShell або REST .

Content-Type: application/x-www-form-urlencoded
Host: login.microsoftonline.com
Accept: application/json
POST https://login.microsoftonline.com/YOUR_TENANT.COM/oauth2/v2.0/token
BODY:
client_id={CLIENT_ID_FROM_AZURE_CLIENT_APP}&scope=https://api.powerplatform.com/.default&client_secret={SECRET_FROM_AZURE_CLIENT_APP}&grant_type=client_credentials

{
  "token_type": "Bearer",
  "expires_in": 3599,
  "ext_expires_in": 3599,
  "access_token": "eyJ0eXAiOiJKV1..."
}

Використовуйте значення access_token у наступних викликах Power Platform API у заголовку HTTP Авторизація. Як зазначалося вище, потік керівника служби не використовує дозволи програм, а замість цього розглядається як Power Platform адміністратор для всіх викликів, які він здійснює.

Див. також

Створення програми принципала служби через API (підготовча версія)
PowerShell — Створення принципала служби

Поділитися через