Бележка
Достъпът до тази страница изисква удостоверяване. Можете да опитате да влезете или да промените директориите.
Достъпът до тази страница изисква удостоверяване. Можете да опитате да промените директориите.
Тази статия предоставя общ преглед на настройката на Microsoft Entra за извикване на API на Power Platform. За достъп до ресурсите, налични чрез API на Power Platform, трябва да получите маркер на носител от Microsoft Entra и да го изпратите като заглавка заедно с всяка заявка. В зависимост от типа на самоличността, която поддържате (потребител или главен субект на услуга), има различни потоци за получаване на този маркер на приносител, както е описано в тази статия.
За да получите маркер на носител с правилните разрешения, изпълнете следните стъпки:
- Създаване на регистрация на приложение във вашия клиент microsoft Entra
- Конфигуриране на разрешения за API
- Конфигуриране на URI за платформа и пренасочване
- (По избор) Конфигуриране на сертификати и тайни
- Искане на маркер за достъп
Стъпка 1. Създайте регистрация на заявление във вашия Microsoft Entra клиент
- Отидете в портала Azure.
- Изберете ИД на Microsoft Entra в горната част на страницата. След това изберете + Добавяне на> приложение.
- Попълнете страницата Регистриране на приложение :
- Name – Дайте на приложението разпознаваемо име, като например SDK на администратор на Платформата Power.
- Поддържани типове акаунти – изберете Само за един клиент – <името> на вашата фирма.
- URI за пренасочване – пропуснете това засега. Можете да го конфигурирате в стъпка 3.
- Изберете Регистриране , за да създадете приложението. След като регистрацията завърши, обърнете внимание на ИД на приложение (клиент) и ИД на указател (клиент) от страницата общ преглед – трябва да имате и двете стойности по-късно.
Можете също да създадете регистрацията с помощта на CLI за Azure:
az login
az ad app create --display-name "Power Platform Admin SDK" --sign-in-audience AzureADMyOrg
Командата връща JSON обект. Обърнете внимание на appId стойността – тази стойност е вашият ИД на клиент.
Стъпка 2. Конфигурация на разрешения на API
В новата си регистрация на приложение отидете на раздела Управление – разрешения за API . Под секцията Конфигуриране на разрешения изберете Добавяне на разрешение. В диалоговия прозорец изберете раздела API, които моята организация използва , и след това потърсете API на платформата Power. Може да видите няколко записа с име, подобно на това, така че се уверете, че използвате този с GUID 8578e004-a5c6-46e7-913e-12f58912df43.
Ако не виждате API на Power Platform, показан в списъка при търсене по GUID, все още може да имате достъп до него, но видимостта не се обновява. За принудително обновяване изпълнете следния скрипт:
#Install the Microsoft Graph PowerShell SDK module
Install-Module Microsoft.Graph -Scope CurrentUser -Repository PSGallery -Force
Connect-MgGraph
New-MgServicePrincipal -AppId 8578e004-a5c6-46e7-913e-12f58912df43 -DisplayName "Power Platform API"
Оттук изберете разрешенията, от които имате нужда. Тези разрешения са групирани по пространства на имената. В пространството на имената виждате типове ресурси и действия, като например AppManagement.ApplicationPackages.Read, което дава разрешения за четене за пакетите приложения. За повече информация вж. статията Справка за разрешенията .
Бележка
API за платформата Power използва делегирани разрешения само в момента. За приложения, които се изпълняват с потребителски контекст, поискайте делегирани разрешения с помощта на параметъра за обхват . Тези разрешения делегират привилегиите на влезлия потребител на вашето приложение, така че да може да действа като потребител, когато извиква крайни точки на API за Платформата Power.
За самоличности на главен субект на услуга не използвайте разрешения за приложения. Вместо това, след като създадете своята регистрация на приложение, му присвоете RBAC роля, за да дадете разрешения с обхват (като сътрудник или четец). За повече информация вижте Урок: Присвояване на RBAC роли на главен субект на услуга.
След като добавите необходимите разрешения за приложението, изберете Даване на съгласие на администратор , за да завършите настройката. С предоставянето на съгласие на администратор вие разрешавате разрешенията за всички потребители в клиента, така че да не получават подкана с диалогов прозорец за интерактивно съгласие при първото използване на вашето приложение. Ако предпочитате интерактивно съгласие за потребител, следвайте платформата за самоличност на Microsoft и потока от кодове за удостоверяване на OAuth 2.0.
Можете също да дадете съгласие на администратор, като използвате CLI за Azure:
# Replace <app-id> with your application (client) ID
az ad app permission admin-consent --id <app-id>
Стъпка 3. Конфигуриране на URI за платформа и пренасочване
SDK, скриптове на PowerShell и настолни приложения, които се удостоверяват от името на потребител, изискват URI за пренасочване, така че Microsoft Entra да може да върне маркери обратно към вашето приложение след удостоверяване.
В рамките на регистрацията на приложението отидете на Управление – удостоверяване.
Изберете Добавяне на URI за пренасочване, след което изберете Мобилни и настолни приложения.
Изберете следния вграден URI за пренасочване:
https://login.microsoftonline.com/common/oauth2/nativeclientИзберете Конфигуриране за записване.
Можете също да добавите URI за пренасочване, като използвате CLI за Azure:
# Replace <app-id> with your application (client) ID
az ad app update --id <app-id> --public-client-redirect-uris https://login.microsoftonline.com/common/oauth2/nativeclient
Настройка на публичен клиент
Под секцията Разширени настройки на същия раздел Удостоверяване има превключвател Разрешаване на публични клиентски потоци . Задайте този превключвател на Да само ако планирате да използвате потока с идентификационни данни за паролата на собственика на ресурса (ROPC), който изпраща потребителско име и парола директно в тялото на искането за маркер.
Този поток не работи за акаунти, които имат разрешено многофакторно удостоверяване. За интерактивни потоци с код на браузър или устройство не е необходимо да разрешавате тази настройка.
Стъпка 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. Получавате отговор, който можете да използвате, за да извършвате следващи повиквания към 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..."
}
Използвайте стойност маркер за достъп при последващи извиквания към Power Platform API с помощта на HTTP заглавка Разрешение.
Поток на главницата на услугата
Не забравяйте да прочетете раздела Конфигуриране на сертификати и тайни . След това изпратете POST заявка чрез HTTP to Microsoft Entra ID с полезен товар на тайна клиент. Този метод за удостоверяване често се нарича удостоверяване на субект на услуга.
Важно
Преди да използвате удостоверяване на субекта на услуга, изпълнете стъпки от 1 до 4 по-горе в тази статия, за да създадете и конфигурирате регистрацията на приложението със сертификат или тайна на клиента. След това задайте на субекта на услугата RBAC роля, за да управлявате нейното ниво на достъп. За да научите повече, вижте Урок: Присвояване на RBAC роли на субекта на услугата.
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
Предишният пример съдържа контейнери, които можете да извлечете от вашето клиентско приложение в ИД на Microsoft Entra. Получавате отговор, който можете да използвате, за да извършвате следващи повиквания към API на Power Platform.
{
"token_type": "Bearer",
"expires_in": 3599,
"ext_expires_in": 3599,
"access_token": "eyJ0eXAiOiJKV1..."
}
Използвайте стойност маркер за достъп при последващи извиквания към Power Platform API с помощта на HTTP заглавка Разрешение. Ефективните разрешения на субекта на услугата се определят от ролята RBAC, която му е присвоена. За да научите как да присвоите роля, вижте Урок: Присвояване на RBAC роли на субекта на услугата.
Бърз старт с CLI за Azure
Следващият скрипт създава регистрация на приложение от край до край. Изпълнете всяка команда поред и заместете стойностите в контейнерите със свои собствени.
# Sign in to Azure CLI
az login
# Create the app registration (single tenant)
az ad app create --display-name "Power Platform Admin SDK" --sign-in-audience AzureADMyOrg
# Save the app ID from the output, then create a service principal for it
az ad sp create --id <app-id>
# Add a delegated permission (example: AppManagement.ApplicationPackages.Read)
# The --api value is the Power Platform API app ID.
# The --api-permissions value is the permission ID and type (Scope = delegated).
# Repeat this command for each permission you need. See the Permission reference for IDs.
az ad app permission add --id <app-id> \
--api 8578e004-a5c6-46e7-913e-12f58912df43 \
--api-permissions <permission-id>=Scope
# Grant admin consent so users aren't prompted individually
az ad app permission admin-consent --id <app-id>
# Add the native client redirect URI for interactive auth
az ad app update --id <app-id> \
--public-client-redirect-uris https://login.microsoftonline.com/common/oauth2/nativeclient
След като изпълните тези команди, можете да използвате регистрацията на приложението с SDK, PowerShell или директни REST повиквания. За да потърсите ИД на разрешение за параметъра --api-permissions , вж. препратката към Разрешение.
Отстраняване на често срещани проблеми
Грешки "Изисква се съгласие" или "изисква одобрение от администратор"
Тази грешка възниква, когато администраторът не е дал съгласието си за разрешенията за API за регистрацията на вашето приложение. Отидете на Регистрации на> приложения, вашите > на приложение и изберете Даване на съгласие на администратор.
Друга възможност е да избягате:
az ad app permission admin-consent --id <app-id>
Грешки "Потребителят не е присвоен на роля за приложението"
Тази грешка означава, че корпоративното приложение, свързано с вашата регистрация на приложение, има зададено присвояване на потребител , зададено на Да. Когато тази настройка е разрешена, само потребители или групи, които са изрично присвоени на приложението, могат да влизат. За да коригирате тази грешка, изправете едно от следните действия:
- Отидете вПриложения> на Microsoft Entra ID> Enterprise, за да зададете > на вашето приложение, и задайте Присвояване, което се изисква на Не.
- Добавете съответните потребители или групи за защита под Потребители и групи.
Правила за условен достъп, които блокират достъпа
Ако вашата организация прилага правила за условен достъп, те може да блокират придобиването на маркери за регистрирането на приложението ви. Често срещаните причини включват изисквания за съответствие на устройството, ограничения за местоположението или правила, базирани на риск. Работете с вашия администратор на Microsoft Entra, за да изключите регистрацията на приложението от правилата или да се уверите, че клиентите отговарят на изискванията на правилата.
"Power Platform API" не е намерено в програмата за избор на API
Ако търсенето на API за Power Platform по име или GUID в диалоговия прозорец за разрешения на API не връща никакви резултати, субектът на услугата не е създаден във вашия клиент. Следвайте стъпките за принудително обновяване в стъпка 2 , за да го създадете.
Удостоверяване с SDK на Power Platform и PowerShell
Следващите примери показват как да извършите удостоверяване и да направите примерно повикване на API с помощта на всеки SDK и PowerShell. Преди да изпълните тези примери, изпълнете стъпки от 1 до 3 по-горе в тази статия, за да създадете и конфигурирате регистрацията на вашето приложение.
Интерактивно удостоверяване (делегиран потребител)
Интерактивното удостоверяване отваря прозорец на браузъра, в който потребителят да влезе. Този поток работи най-добре за скриптове за разработчици, инструменти за администриране и всеки сценарий, при който потребителят присъства.
# Sign in interactively (opens a browser)
Connect-AzAccount
# Get an access token for the Power Platform API
$token = Get-AzAccessToken -ResourceUrl "https://api.powerplatform.com"
# Call the List Environments endpoint as an example
$headers = @{ Authorization = "Bearer $($token.Token)" }
$environments = Invoke-RestMethod -Uri "https://api.powerplatform.com/environmentmanagement/environments?api-version=2024-10-01" -Headers $headers
$environments.value | Format-Table name, properties.displayName
Поверителен клиент (главен субект на услуга)
Поверителното удостоверяване на клиента използва тайна на клиента или сертификат и не изисква взаимодействие с потребителя. Този поток за удостоверяване е най-подходящ за фонови услуги, канали и автоматизация.
Важно
Преди да използвате удостоверяване на главен субект на услуга, изпълнете стъпки от 1 до 4 по-горе, за да създадете и конфигурирате своята регистрация на приложение със сертификат или тайна на клиента. След това задайте на субекта на услугата RBAC роля, за да управлявате нейното ниво на достъп. За повече информация вижте Урок: Присвояване на роли на RBAC на субекта на услугата.
$tenantId = "YOUR_TENANT_ID"
$clientId = "YOUR_CLIENT_ID"
$clientSecret = "YOUR_CLIENT_SECRET"
# Request a token using client credentials
$body = @{
client_id = $clientId
scope = "https://api.powerplatform.com/.default"
client_secret = $clientSecret
grant_type = "client_credentials"
}
$tokenResponse = Invoke-RestMethod -Method Post `
-Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" `
-ContentType "application/x-www-form-urlencoded" `
-Body $body
# Call the List Environments endpoint as an example
$headers = @{ Authorization = "Bearer $($tokenResponse.access_token)" }
$environments = Invoke-RestMethod -Uri "https://api.powerplatform.com/environmentmanagement/environments?api-version=2024-10-01" -Headers $headers
$environments.value | Format-Table name, properties.displayName
Свързано съдържание
Урок: Присвояване на RBAC роли на субекта на услугата
Управление на достъпа, базирано на роли, за центъра за администриране на платформата Power
Препратка към разрешение