Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article fournit une vue d’ensemble de la configuration de Microsoft Entra pour appeler l’API Power Platform. Pour accéder aux ressources disponibles via l’API Power Platform, vous devez obtenir un jeton du porteur à partir de Microsoft Entra et l’envoyer en tant qu’en-tête avec chaque requête. Selon le type d’identité que vous prendz en charge (utilisateur et principal de service), il existe différents flux pour obtenir ce jeton du porteur, comme décrit dans cet article.
Pour obtenir un jeton du porteur avec les autorisations appropriées, procédez comme suit :
- Créer une inscription d’application dans votre locataire Microsoft Entra
- Configurer les autorisations d’API
- Configurer l’URI de plateforme et de redirection
- (Facultatif) Configurer des certificats et des secrets
- Demander un jeton d’accès
Étape 1. Créer un enregistrement d’application dans votre client Microsoft Entra
- Accédez au portail Azure.
- Sélectionnez l’ID Microsoft Entra en haut de la page. Sélectionnez ensuite + Ajouter une>inscription d’application.
- Renseignez la page Inscrire une application :
- Nom : donnez à l’application un nom reconnaissable, tel que le Kit de développement logiciel (SDK) d’administration Power Platform.
- Types de comptes pris en charge : sélectionnez un seul locataire , <le nom> de votre entreprise.
- URI de redirection : ignorez-le pour l’instant. Vous la configurez à l’étape 3.
- Sélectionnez Inscrire pour créer l’application. Une fois l’inscription terminée, notez l’ID d’application (client) et l’ID d’annuaire (locataire) dans la page vue d’ensemble . Vous avez besoin des deux valeurs ultérieurement.
Vous pouvez également créer l’inscription à l’aide d’Azure CLI :
az login
az ad app create --display-name "Power Platform Admin SDK" --sign-in-audience AzureADMyOrg
La commande retourne un objet JSON. Notez la appId valeur : cette valeur est votre ID client.
Étape 2. Configurer les autorisations API
Dans votre nouvelle inscription d’application, accédez à l’onglet Gérer - Autorisations d’API . Dans la section Configurer les autorisations , sélectionnez Ajouter une autorisation. Dans la boîte de dialogue, sélectionnez les API que mon organisation utilise l’onglet, puis recherchez l’API Power Platform. Vous pouvez voir plusieurs entrées portant un nom similaire à celui-ci. Veillez donc à l’utiliser avec le GUID 8578e004-a5c6-46e7-913e-12f58912df43.
Si vous ne voyez pas l’API Power Platform affichée dans la liste lors de la recherche par GUID, vous pouvez toujours y avoir accès, mais la visibilité n’est pas actualisée. Pour forcer une actualisation, exécutez le script suivant :
#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"
À partir de là, sélectionnez les autorisations dont vous avez besoin. Ces autorisations sont regroupées par espaces de noms. Dans un espace de noms, vous voyez des types de ressources et des actions, tels que AppManagement.ApplicationPackages.Read, qui donnent des autorisations de lecture pour les packages d’application. Pour plus d’informations, consultez l’article de référence sur les autorisations .
Note
L’API Power Platform utilise des autorisations déléguées uniquement pour l’instant. Pour les applications qui s’exécutent avec un contexte utilisateur, demandez des autorisations déléguées à l’aide du paramètre d’étendue . Ces autorisations délèguent les privilèges de l’utilisateur connecté à votre application, afin qu’elle puisse agir en tant qu’utilisateur lors de l’appel de points de terminaison d’API Power Platform.
Pour les identités de principal de service, n’utilisez pas les autorisations d’application. Au lieu de cela, après avoir créé votre inscription d’application, attribuez-lui un rôle RBAC pour accorder des autorisations délimitées (par exemple , Contributeur ou Lecteur). Pour plus d’informations, consultez Tutoriel : Attribuer des rôles RBAC aux principaux de service.
Après avoir ajouté les autorisations requises à l’application, sélectionnez Accorder le consentement de l’administrateur pour terminer l’installation. En accordant le consentement administrateur, vous autorisez les autorisations pour tous les utilisateurs du locataire afin qu’ils ne soient pas invités à utiliser une boîte de dialogue de consentement interactif la première fois qu’ils utilisent votre application. Si vous préférez un consentement interactif par utilisateur, suivez la plateforme d’identités Microsoft et le flux de code d’autorisation OAuth 2.0.
Vous pouvez également accorder le consentement de l’administrateur à l’aide d’Azure CLI :
# Replace <app-id> with your application (client) ID
az ad app permission admin-consent --id <app-id>
Étape 3. Configurer l’URI de plateforme et de redirection
Les sdk, les scripts PowerShell et les applications de bureau qui s’authentifient pour le compte d’un utilisateur nécessitent un URI de redirection afin que Microsoft Entra puisse retourner des jetons à votre application après l’authentification.
Dans l’inscription de votre application, accédez à Gérer - Authentification.
Sélectionnez Ajouter un URI de redirection, puis choisissez Applications mobiles et de bureau.
Sélectionnez l’URI de redirection intégré suivant :
https://login.microsoftonline.com/common/oauth2/nativeclientSélectionnez Configurer pour enregistrer.
Vous pouvez également ajouter l’URI de redirection à l’aide d’Azure CLI :
# 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
Paramètre client public
Sous la section Paramètres avancés sous le même onglet Authentification , il existe un bouton bascule Autoriser les flux de clients publics . Définissez ce bouton bascule sur Oui uniquement si vous envisagez d’utiliser le flux ROPC (Resource Owner Password Credentials), qui envoie un nom d’utilisateur et un mot de passe directement dans le corps de la demande de jeton.
Ce flux ne fonctionne pas pour les comptes dont l’authentification multifacteur est activée. Pour les flux de code interactifs du navigateur ou de l’appareil, vous n’avez pas besoin d’activer ce paramètre.
Étape 4. (Facultatif) Configurer des certificats et des secrets
Si votre application nécessite la lecture et l’écriture de ressources comme elle-même, également appelée principal de service, il existe deux façons de s’authentifier. Pour utiliser des certificats, accédez à Gérer - Certificats et secrets. Dans la section Certificats , chargez un certificat x509 que vous pouvez utiliser pour vous authentifier.
L’autre façon consiste à utiliser la section Clés secrètes pour générer une clé secrète client. Enregistrez la clé secrète dans un endroit sûr pour une utilisation avec vos besoins d’automatisation. Les options de certificat ou de secret vous permettent de vous authentifier auprès de Microsoft Entra et de recevoir un jeton pour ce client, que vous transmettez aux API REST ou aux applets de commande PowerShell.
Étape 5. Demander un jeton d’accès
Vous pouvez obtenir un jeton du porteur d’accès de deux manières : l’une est pour le nom d’utilisateur et le mot de passe, et l’autre pour les principaux de service.
Flux de nom d′utilisateur et mot de passe
Veillez à lire la section du client public. Ensuite, envoyez une requête POST via HTTP à Microsoft Entra ID avec une charge utile de nom d’utilisateur et de mot de passe.
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
L’exemple précédent contient des espaces réservés que vous pouvez récupérer à partir de votre application cliente dans Microsoft Entra ID. Vous recevez une réponse que vous pouvez utiliser pour effectuer des appels ultérieurs à l’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..."
}
Utilisez la valeur access_token dans les appels ultérieurs à l’API Power Platform à l’aide de l’en-tête HTTP Autorisation.
Flux du principal de service
Veillez à lire la section Configurer les certificats et les secrets . Ensuite, envoyez une requête POST via HTTP à Microsoft Entra ID avec une charge utile de clé secrète client. Cette méthode d’authentification est souvent appelée authentification du principal de service.
Important
Avant d’utiliser l’authentification du principal de service, suivez les étapes 1 à 4 plus haut dans cet article pour créer et configurer votre inscription d’application avec un certificat ou une clé secrète client. Attribuez ensuite au principal de service un rôle RBAC pour contrôler son niveau d’accès. Pour plus d’informations, consultez Tutoriel : Attribuer des rôles RBAC aux principaux de service.
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
L’exemple précédent contient des espaces réservés que vous pouvez récupérer à partir de votre application cliente dans Microsoft Entra ID. Vous recevez une réponse que vous pouvez utiliser pour effectuer des appels ultérieurs à l’API Power Platform.
{
"token_type": "Bearer",
"expires_in": 3599,
"ext_expires_in": 3599,
"access_token": "eyJ0eXAiOiJKV1..."
}
Utilisez la valeur access_token dans les appels ultérieurs à l’API Power Platform à l’aide de l’en-tête HTTP Autorisation. Les autorisations effectives du principal de service sont déterminées par le rôle RBAC qui lui est attribué. Pour savoir comment attribuer un rôle, consultez Tutoriel : Attribuer des rôles RBAC aux principaux de service.
Démarrage rapide avec Azure CLI
Le script suivant crée une inscription d’application de bout en bout. Exécutez chaque commande dans l’ordre et remplacez les valeurs d’espace réservé par vos propres valeurs.
# 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
Après avoir exécuté ces commandes, vous pouvez utiliser l’inscription de votre application avec les kits SDK, PowerShell ou les appels REST directs. Pour rechercher les ID d’autorisation du --api-permissions paramètre, consultez la référence d’autorisation.
Dépannage des problèmes courants
Erreurs « Consentement requis » ou « besoin d’approbation d’administrateur »
Cette erreur se produit lorsque l’administrateur n’a pas consenti aux autorisations d’API sur l’inscription de votre application. Accédez aux inscriptions d’applications avec les>autorisations d’API de votre application>, puis sélectionnez Accorder le consentement de l’administrateur.
Sinon, exécutez :
az ad app permission admin-consent --id <app-id>
Erreurs « L’utilisateur n’est pas affecté à un rôle pour l’application »
Cette erreur signifie que l’application d’entreprise associée à l’inscription de votre application a une attribution d’utilisateur définie sur Oui. Lorsque ce paramètre est activé, seuls les utilisateurs ou groupes explicitement affectés à l’application peuvent se connecter. Pour corriger cette erreur, effectuez l’une des actions suivantes :
- Accédez aux applications Microsoft Entra ID> Enterprise de vospropriétés>d’application et définissez l’affectation> requise sur Non.
- Ajoutez les utilisateurs ou groupes de sécurité pertinents sous Utilisateurs et groupes.
Stratégies d’accès conditionnel bloquant l’accès
Si votre organisation applique des stratégies d’accès conditionnel, elle peut bloquer l’acquisition de jetons pour l’inscription de votre application. Les causes courantes incluent les exigences de conformité des appareils, les restrictions d’emplacement ou les stratégies basées sur les risques. Collaborez avec votre administrateur Microsoft Entra pour exclure votre inscription d’application de la stratégie ou vérifiez que les clients répondent aux exigences de la stratégie.
« API Power Platform » introuvable dans le sélecteur d’API
Si vous recherchez l’API Power Platform par nom ou GUID dans la boîte de dialogue Autorisations de l’API ne retourne aucun résultat, le principal de service n’est pas créé dans votre locataire. Suivez les étapes d’actualisation forcée à l’étape 2 pour la créer.
S’authentifier avec les kits SDK Power Platform et PowerShell
Les exemples suivants montrent comment authentifier et effectuer un exemple d’appel d’API à l’aide de chaque kit SDK et powerShell. Avant d’exécuter ces exemples, suivez les étapes 1 à 3 plus haut dans cet article pour créer et configurer votre inscription d’application.
Authentification interactive (utilisateur délégué)
L’authentification interactive ouvre une fenêtre de navigateur pour que l’utilisateur se connecte. Ce flux fonctionne le mieux pour les scripts de développeur, les outils d’administration et tout scénario dans lequel un utilisateur est présent.
# 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
Client confidentiel (principal de service)
L’authentification client confidentielle utilise une clé secrète client ou un certificat et ne nécessite pas d’interaction utilisateur. Ce flux d’authentification est idéal pour les services en arrière-plan, les pipelines et l’automatisation.
Important
Avant d’utiliser l’authentification du principal de service, suivez les étapes 1 à 4 ci-dessus pour créer et configurer votre inscription d’application avec un certificat ou une clé secrète client. Attribuez ensuite au principal de service un rôle RBAC pour contrôler son niveau d’accès. Pour plus d’informations, consultez Tutoriel : Attribuer des rôles RBAC aux principaux de service.
$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
Contenu connexe
Tutoriel : Attribuer des rôles RBAC aux principaux de service
Contrôle d’accès en fonction du rôle pour le Centre d’administration Power Platform
Informations de référence sur l’autorisation