Authentification (version préliminaire)

Article
01/02/2024

Cet article offre une vue d’ensemble de la configuration de Microsoft Entra pour appeler l’API Power Platform (version préliminaire). Pour accéder aux ressources disponibles via l’API Power Platform, vous devez obtenir un jeton du porteur d’Microsoft Entra et l’envoyer comme en-tête avec chaque requête. Selon le type d’identité que vous prenez en charge (utilisateur ou principal de service), il existe différents flux pour obtenir ce jeton du porteur, comme décrit dans cet article.

Les étapes suivantes sont nécessaires pour obtenir un jeton du porteur avec les autorisations appropriées :

Créer un enregistrement d’application dans votre client Microsoft Entra
Configurer les autorisations API
Configurer le client public (facultatif)
Configurer les certificats et les secrets (facultatif)
Demander un jeton d’accès

Étape 1. Créer un enregistrement de l’application

Accédez à la page Enregistrement de l’application Microsoft Entra et créez une inscription. Donnez un nom à l’application et veillez à ce que l’option Client unique soit sélectionnée. Vous pouvez ignorer la configuration de l’URI de redirection.

Étape 2. Configurer les autorisations API

Dans votre nouvel enregistrement d’application, accédez à l’onglet Gérer – Autorisations API. Sous la section Configurer les autorisations, sélectionnez Ajouter une autorisation. Dans la fenêtre de dialogue qui s’ouvre, sélectionnez l’onglet API utilisées par mon organisation, puis recherchez API Power Platform. Vous pouvez voir plusieurs entrées avec un nom similaire à celui-ci, alors assurez-vous que vous utilisez celle avec le GUID 8578e004-a5c6-46e7-913e-12f58912df43.

Si l’API Power Platform ne s’affiche dans la liste lors d’une recherche par GUID, il est possible que vous y ayez toujours accès mais que la visibilité n’est pas actualisée. Pour forcer une actualisation, exécutez le script PowerShell ci-dessous :

#Install the Microsoft Entra the module
Install-Module AzureAD

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

À partir de là, vous devez sélectionner les autorisations dont vous avez besoin. Celles-ci sont regroupées par Espaces de noms. Dans un espace de noms, vous verrez des types de ressources et des actions, par exemple AppManagement.ApplicationPackages.Read, qui fournissent des autorisations de lecture pour les packages d’application. Pour plus d’informations, consultez notre article Référence d’autorisation.

Note

L’API Power Platform utilise uniquement les autorisations déléguées pour le moment. Pour les applications qui s’exécutent avec un contexte utilisateur, vous demandez des autorisations déléguées à l’aide du paramètre portée. Ces autorisations délèguent les privilèges de l’utilisateur connecté à votre application, lui permettant d’agir en tant qu’utilisateur lors de l’appel des points de terminaison de l’API Power Platform.

Pour les identités de principal de service, les autorisations d’application ne sont pas utilisées. Au lieu de cela, les principaux de service sont traités aujourd’hui en tant qu’administrateurs Power Platform et doivent être enregistrés en suivant la procédure PowerShell – Créer un principal de service.

Une fois les autorisations requises ajoutées à l’application, sélectionnez Accorder un consentement à l’administrateur pour terminer la configuration. Cela est nécessaire dans les cas où vous souhaitez autoriser les utilisateurs à accéder immédiatement à votre application, au lieu d’exiger une expérience de consentement interactive. Si vous pouvez prendre en charge le consentement interactif, nous vous recommandons de suivre la plateforme d’identité Microsoft et le flux du code d’autorisation OAuth 2.0.

Étape 3. Configurer le client public (facultatif)

Si votre application nécessite des ressources de lecture et d’écriture pour le compte d’un utilisateur, vous devez activer le paramètre Client public. C’est l’unique façon pour Microsoft Entra ID d’accepter les propriétés de nom d’utilisateur et de mot de passe dans le corps de votre demande de jeton. Notez également que si vous envisagez d’utiliser cette fonctionnalité, elle ne fonctionnera pas pour les comptes pour lesquels l’authentification multifacteur est activée.

Pour l’activer, accédez à l’onglet Gérer – Authentification. Sous la section Paramètres avancés, définissez le commutateur Client public sur Oui.

Étape 4. Configurer les certificats et les secrets (facultatif)

Si votre application nécessite des ressources de lecture et d’écriture, également appelées principal de service, il existe deux façons de s’authentifier. Pour utiliser des certificats, accédez à l’onglet Gérer – Certificats et secrets. Sous 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 passez aux API REST ou aux applets de commande PowerShell.

Étape 5. Demander un jeton d’accès

Il existe deux manières d’obtenir un jeton du porteur d’accès. L’un est pour le nom d’utilisateur et le mot de passe et l’autre est pour les principaux de service.

Flux de nom d′utilisateur et mot de passe

Assurez-vous de lire la section Client public ci-dessus. 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 ci-dessus 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 qui peut être utilisée pour passer 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

Assurez-vous de lire la section Certificats et clés secrètes ci-dessus. Ensuite, envoyez une requête POST via HTTP à Microsoft Entra ID avec une charge utile de clé secrète client. Ceci est souvent appelé authentification du principal de service.

Important

Cela ne peut être utilisé qu’après avoir enregistré cet ID d’application cliente auprès de Microsoft Power Platform en suivant la documentation PowerShell ou REST associée.

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..."
}

Utilisez la valeur access_token dans les appels ultérieurs à l’API Power Platform à l’aide de l’en-tête HTTP Autorisation. Comme indiqué ci-dessus, le flux du principal de service n’utilise pas les autorisations de l’application et, pour l’instant, est traité plutôt comme un administrateur Power Platform pour tous les appels qu’il effectue.

Voir aussi

Créer une application de principal de service via l’API (version préliminaire)
PowerShell – Créer un principal de service