Autentificare (previzualizare)
Acest articol oferă o prezentare generală a Azure Active Directory (Azure AD) configurarea pentru apelare Power Platform API (previzualizare). Pentru a accesa resursele disponibile prin Power Platform API, trebuie să obțineți un token purtător de la Azure AD și trimiteți-l ca antet împreună cu fiecare cerere. În funcție de tipul de identitate pe care îl suportați (utilizator vs principal de serviciu), există fluxuri diferite pentru a obține acest simbol purtător. Acestea sunt prezentate mai jos.
Următorii pași sunt necesari pentru a obține un token purtător cu permisiunile corecte:
- Creați o cerere de înregistrare în dvs Azure AD chiriaş
- Configurați permisiunile API
- Configurați clientul public (opțional)
- Configurați certificate și secrete (opțional)
- Solicitați un token de acces
Pasul 1. Creați o înregistrare a aplicației
Navigați la Azure AD înregistrarea aplicației pagina și creați o nouă înregistrare. Dați un nume aplicației și asigurați-vă că Chiriaș unic este selectată opțiunea. Puteți sări peste configurarea URI de redirecționare.
Pasul 2. Configurați permisiunile API
În noua înregistrare a aplicației, navigați la Gestionare - Permisiuni API fila. Sub Configurați permisiunile secțiune, selectați Adăugați o permisiune. În fereastra de dialog care se deschide, selectați API-urile pe care le folosește organizația mea fila, apoi căutați Power Platform API. Este posibil să vedeți mai multe intrări cu un nume similar cu acesta, deci asigurați-vă că îl utilizați pe cel cu GUID 8578e004-a5c6-46e7-913e-12f58912df43.
Daca nu vezi Power Platform API care apare în listă atunci când căutați după GUID, este posibil să aveți în continuare acces la el, dar vizibilitatea nu este reîmprospătată. Pentru a forța o reîmprospătare, executați scriptul PowerShell de mai jos:
#Install the Azure AD the module
Install-Module AzureAD
Connect-AzureAD
New-AzureADServicePrincipal -AppId 8578e004-a5c6-46e7-913e-12f58912df43 -DisplayName "Power Platform API"
De aici, trebuie să selectați permisiunile de care aveți nevoie. Acestea sunt grupate după Spații de nume. Într-un spațiu de nume, veți vedea tipuri de resurse și acțiuni, de exemplu AppManagement.ApplicationPackages.Read care va oferi permisiuni de citire pentru pachetele de aplicații. Pentru mai multe detalii, consultați Referință de permisiune articol.
Notă
Power Platform API folosește permisiunile delegate numai în acest moment. Pentru aplicațiile care rulează cu un context de utilizator, solicitați permisiuni delegate folosind domeniul de aplicare parametru. Aceste permisiuni delegă privilegiile utilizatorului conectat aplicației dvs., permițându-i acestuia să acționeze ca utilizator atunci când apelează Power Platform Puncte finale API.
Pentru identitățile principale de serviciu, permisiunile aplicației nu sunt utilizate. În schimb, directorii de servicii sunt tratați ca Power Platform Administratori astăzi și trebuie să fie înregistrate urmând PowerShell - Creați principal de serviciu.
După ce permisiunile necesare sunt adăugate la aplicație, selectați Acordați consimțământul administratorului pentru a finaliza configurarea. Acest lucru este necesar pentru cazurile în care doriți să permiteți utilizatorilor să vă acceseze aplicația imediat, în loc să solicitați o experiență interactivă de consimțământ. Dacă puteți susține consimțământul interactiv, vă recomandăm să urmați Platforma de identitate Microsoft și fluxul de coduri de autorizare OAuth 2.0.
Pasul 3. Configurați clientul public (opțional)
Dacă aplicația dvs. va necesita resurse de citire și scriere în numele unui utilizator, va trebui să activați setarea Public Client. Acesta este singurul mod în care Azure AD va accepta proprietățile numelui de utilizator și parolei în corpul solicitării dvs. de simbol. De asemenea, rețineți că, dacă intenționați să utilizați această funcție, aceasta nu va funcționa pentru conturile care au activată autentificarea cu mai mulți factori.
Pentru a activa, vizitați Gestionare - Autentificare fila. Sub Setari avansate secțiunea, setați Client public schimba cu da.
Pasul 4. Configurați certificate și secrete (opțional)
Dacă aplicația dvs. va necesita resurse de citire și scriere ca ea însăși - cunoscută și ca principal de serviciu, există două moduri de autentificare. Pentru a utiliza certificate, navigați la Gestionare - Certificate și secrete fila. Sub Certificate secțiunea, încărcați un certificat x509 pe care îl puteți utiliza pentru a vă autentifica. Cealaltă modalitate este de a folosi Secrete secțiune pentru a genera un secret de client. Salvați secretul într-o locație sigură pentru a fi utilizat cu nevoile dvs. de automatizare. Certificatul sau opțiunile secrete vă vor permite să vă autentificați cu Azure AD și primiți un token pentru acest client, din care veți trece fie la REST API, fie la cmdleturile PowerShell.
Pasul 5. Solicitați un token de acces
Există două moduri de a obține un token de purtător de acces. Unul este pentru numele de utilizator și parola, iar celălalt este pentru directorii de servicii.
Flux de nume de utilizator și parole
Asigurați-vă că citiți secțiunea Public Client de mai sus. Apoi, trimiteți o solicitare POST prin HTTP către Azure AD cu un nume de utilizator și o parolă.
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
Exemplul de mai sus conține substituenți pe care îi puteți prelua din aplicația dvs. client în Azure Active Directory. Veți primi un răspuns care poate fi utilizat pentru a efectua apeluri ulterioare către 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..."
}
Folosește jeton de acces valoare în apelurile ulterioare către Power Platform API cu Autorizare Antet HTTP.
Fluxul principal al serviciului
Asigurați-vă că citiți secțiunea Certificate și secrete de mai sus. Apoi, trimiteți o solicitare POST prin HTTP către Azure AD cu o sarcină utilă secretă a clientului. Aceasta este adesea denumită autentificare principală a serviciului. Acest lucru poate fi utilizat numai după ce ați înregistrat acest ID de aplicație client cu Microsoft Power Platform.
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
Exemplul de mai sus conține substituenți pe care îi puteți prelua din aplicația dvs. client în Azure Active Directory. Veți primi un răspuns care poate fi utilizat pentru a efectua apeluri ulterioare către API Power Platform.
{
"token_type": "Bearer",
"expires_in": 3599,
"ext_expires_in": 3599,
"access_token": "eyJ0eXAiOiJKV1..."
}
Folosește jeton de acces valoare în apelurile ulterioare către Power Platform API cu Autorizare Antet HTTP. După cum s-a menționat mai sus, fluxul principal al serviciului nu utilizează permisiunile aplicației și, în schimb, este tratat, deocamdată, ca un Power Platform Administrator pentru toate apelurile pe care le fac.
Consultați și
Crearea unei aplicații principale de serviciu prin API (previzualizare)
PowerShell - Creați principal de serviciu
Feedback
Trimiteți și vizualizați feedback pentru