Options d’authentification
Avant d’utiliser un connecteur dans Azure Logic Apps, Power Automate ou Power Apps, l’utilisateur doit créer une connexion en s’authentifiant auprès du service réseau. Lorsque vous créez un connecteur personnalisé, vous pouvez définir la façon dont l’utilisateur s’authentifiera. Vous pouvez sélectionner le type d’authentification sur l’onglet Sécurité de l’assistant de connecteur en ligne. Les informations supplémentaires que vous devez fournir dépendent du schéma d’authentification sélectionné.
Aucune authentification
Si l’option Aucune authentification est sélectionnée, aucune information supplémentaire n’est requise. L’utilisateur n’a pas besoin de s’authentifier pour créer une connexion au connecteur personnalisé et tout utilisateur anonyme peut utiliser le connecteur. Cette option est sélectionnée uniquement lorsque l’API autorise une utilisation anonyme.
Authentification de base
L’Authentification de base est le type d’authentification le plus simple ; l’utilisateur renseigne le nom d’utilisateur et le mot de passe pour créer la connexion.
Les valeurs saisies dans la colonne Étiquette du paramètre ne sont pas le nom d’utilisateur ou le mot de passe en soi, mais des étiquettes correspondant à ces champs que l’utilisateur voit lorsqu’il crée la connexion.
Dans l’exemple précédent, l’utilisateur est invité à renseigner les champs Utilisateur et Mot de passe pour créer une connexion. Vous devez faire correspondre les étiquettes avec les noms utilisés par l’API afin d’indiquer à l’utilisateur qui crée une connexion les valeurs à utiliser avec cette connexion.
Toute connexion au service qui utilise l’Authentification de base doit utiliser le protocole HTTPS sécurisé pour éviter d’envoyer des informations d’identification non chiffrées.
Authentification par clé API
La clé API est un schéma d’authentification fréquemment utilisé par les services web. Par exemple, Microsoft Azure Functions englobe des paramètres de code dans son modèle par défaut.
Vous devez définir les valeurs suivantes :
Étiquette du paramètre : étiquette de l’invite utilisateur lors de la création d’une connexion.
Nom du paramètre : nom du paramètre qui contiendra la valeur de la clé à chaque demande de service.
Emplacement du paramètre : permet aux créateurs d’envoyer la clé API dans l’en-tête de la demande ou la chaîne de requête lorsqu’ils appellent le service sous-jacent.
Dans l’exemple précédent, l’utilisateur qui crée une connexion voit l’invite suivante :
La valeur saisie est envoyée au service sous-jacent sous la forme d’un en-tête de demande X-API-Key personnalisé.
Le modèle Azure Functions par défaut peut utiliser le code comme nom de paramètre, puis l’envoyer dans une requête en définissant l’emplacement du paramètre sur Requête. L’URL du service ressemble alors à ceci :
https://functionurl.azurewebsites.net?code=user-supplied-code/
Ce fonctionnement est semblable à l’Authentification de base. Nous vous conseillons d’utiliser le schéma d’authentification Clé API uniquement avec le protocole HTTPS, afin d’éviter d’envoyer les clés non chiffrées.
Authentification OAuth 2.0
Le schéma d’authentification OAuth 2.0 est disponible uniquement pour les connecteurs en ligne. Outre la prise en charge de Generic OAuth 2.0, la plateforme permet d’implémenter des services spécifiques, notamment Microsoft Entra ID, GitHub, le compte Microsoft et plus encore. Lorsqu’ils sont sélectionnés, les modèles de fournisseur d’identité prédéfinis renseignent de nombreux champs requis par OAuth 2.0, avec des valeurs spécifiques au fournisseur, ce qui réduit le travail de saisie pour vous.
Les informations supplémentaires qui seront collectées dépendent du fournisseur d’identité. Le fournisseur Generic OAuth 2.0 requiert les paramètres suivants.
| Paramètre | Description |
|---|---|
| ID client | Identificateur d’application OAuth dans le système cible, saisi manuellement ou généré par le fournisseur lorsque l’application est enregistrée. |
| Clé secrète client | Secret associé à l’application OAuth, généré par le fournisseur. La plupart des fournisseurs peuvent également révoquer les secrets existants et en générer de nouveaux. |
| URL d’autorisation | URL permettant de connecter l’utilisateur et d’autoriser l’application, par exemple : https://www.facebook.com/v9.0/dialog/oauth ou https://login.salesforce.com/services/oauth2/authorize. |
| URL de jeton | URL permettant de récupérer un jeton une fois l’application autorisée par l’utilisateur, par exemple : https://graph.facebook.com/v9.0/oauth/access_token ou https://mycompany.salesforce.com/mycompany.salesforce.com. |
| URL d’actualisation | URL utilisée pour récupérer un nouveau jeton au moyen d’un jeton d’actualisation après expiration de l’original. Cette URL est généralement la même que l’URL de jeton pour la plupart des services. |
| Étendue | Chaîne représentant les autorisations que vous cherchez à obtenir de la part de l’utilisateur. Laissez ce paramètre vide ou reportez-vous à la documentation du fournisseur pour spécifier l’étendue de l’autorisation requise par votre application. |
Vous devez enregistrer le connecteur auprès du fournisseur d’identité en tant qu’application cliente ; les détails d’enregistrement spécifiques dépendent du fournisseur, qui les documente. Par exemple, pour s’authentifier avec Facebook, un créateur créerait une application Facebook avec ses outils de développement. Les paramètres ID client et Clé secrète client font partie des spécifications OAuth 2.0. Ils sont fournis par tous les fournisseurs d’identité OAuth 2.0 lors de l’enregistrement de l’application. La valeur URL de redirection doit être incluse avec l’enregistrement de l’application. Dans la configuration du connecteur cette valeur est vide au départ, mais elle devient disponible lorsque la configuration est enregistrée. Elle peut ensuite être copiée et enregistrée avec l’enregistrement du connecteur auprès du fournisseur d’identité.
La plupart des fournisseurs spécifiques nécessitent uniquement un ID client, une clé secrète client et une étendue facultative, car toutes les URL sont prédéfinies pour un service spécifique.
Une fois le connecteur publié et mis à la disposition des utilisateurs, ceux-ci sont invités à saisir leurs informations d’identification pour se connecter au service pendant le processus de création de connexion. Ces informations d’identification sont utilisées par l’application pour obtenir un jeton d’autorisation. Pour chaque demande, ce jeton d’autorisation est envoyé à votre service par le biais de l’en-tête d’autorisation standard.
Le jeton d’autorisation est de courte durée et le runtime du connecteur utilise le processus d’actualisation pour se renouveler afin que les utilisateurs du connecteur ne soient pas impliqués dans le processus d’actualisation.
Authentification Windows
L’option d’authentification Windows est disponible uniquement pour les connexions qui utilisent une passerelle de données locale, lorsque la case Se connecter via une passerelle de données locale est cochée dans l’onglet Général. Aucune information supplémentaire n’est requise pour le schéma d’authentification Windows.
Lors de la création d’une connexion, l’utilisateur doit saisir les informations d’identification Windows pour le service, puis sélectionner l’une des passerelles locales installées.
La spécification OpenAPI utilisée par la plateforme comprend les définitions de clé API et d’authentification de base. Vous pouvez également les modifier en ligne directement au moyen de l’éditeur Swagger. D’autres schémas d’authentification stockent les informations d’authentification séparément en tant que propriétés étendues du connecteur. Bien que ces informations ne soient pas disponibles pour la modification directe de la source en ligne, vous pouvez modifier cette dernière à l’aide de l’outil paconn. L’interface de ligne de commande (CLI) permet la création de scripts de déploiement du connecteur lorsqu’un déploiement automatisé est requis.
Les connecteurs personnalisés prennent en charge plusieurs schémas d’authentification pour répondre aux exigences de l’autorisation d’accès aux services d’API REST sécurisés. Lorsque les services d’API sont déployés et sécurisés dans un environnement Azure AD, l’infrastructure du connecteur offre d’autres avantages. Vous allez en savoir plus sur Azure AD dans l’unité suivante.