S’authentifier auprès d’Azure Communication Services

Chaque interaction client avec Azure Communication Services doit être authentifiée. Dans une architecture classique, une architecture client et serveur, des clés d’accès ou une authentification Microsoft Entra sont utilisées pour l’authentification côté serveur.

Un autre type d’authentification utilise des jetons d’accès utilisateur pour s’authentifier auprès des services nécessitant la participation de l’utilisateur. Par exemple, le service de conversation ou d’appel utilise des jetons d’accès utilisateur pour permettre l’ajout d’utilisateurs à un thread et d’échanger.

Options d’authentification

Le tableau suivant répertorie les Kits de développement logiciel (SDK) Azure Communication Services ainsi que leurs options d’authentification :

Chaque option d’autorisation est décrite brièvement ci-dessous :

Clé d’accès

L’authentification par clé d’accès est adaptée aux applications de service qui s’exécutent dans un environnement de service approuvé. La clé d’accès est accessible sur le Portail Azure Communication Services. L’application de service l’utilise comme informations d’identification pour initialiser les Kits de développement logiciel (SDK) correspondants. Consultez un exemple illustrant la manière dont il est utilisé dans le Kit de développement logiciel (SDK) Identity.

Étant donné que la clé d’accès fait partie de la chaîne de connexion de votre ressource, l’authentification avec une chaîne de connexion est équivalente à l’authentification avec une clé d’accès.

Si vous souhaitez appeler des API Azure Communication Services manuellement à l’aide d’une clé d’accès, vous devez signer la requête. La signature de la requête est expliquée en détail dans un tutoriel.

Pour configurer un principal de service, créez une application inscrite à partir d’Azure CLI. Le point de terminaison et les informations d’identification peuvent ensuite être utilisés pour authentifier les Kits de développement logiciel (SDK). Consultez des exemples d’utilisation du principal de service.

Communication Services prend en charge l’authentification Microsoft Entra ID pour les ressources Communication Services. Vous trouverez plus d’informations sur la prise en charge des identités managées dans la Comment utiliser l’identité managée avec Azure Communication Services.

Authentification Microsoft EntraID

La plateforme Azure fournit un accès en fonction du rôle (RBAC Azure) pour contrôler l’accès aux ressources. Un principal de sécurité Azure RBAC représente un utilisateur, un groupe, un principal de service ou une identité managée demandant l’accès à des ressources Azure. L’authentification Microsoft Entra ID offre une sécurité et une facilité d’utilisation supérieures sur d’autres options d’autorisation.

• Identité managée :

  • En utilisant l’identité managée, vous évitez d’avoir à stocker votre clé d’accès de compte dans votre code, comme vous le faites avec l’autorisation de clé d’accès. Les informations d’identification d’identité managée sont entièrement gérées, pivotées et protégées par la plateforme, ce qui réduit le risque d’exposition des informations d’identification.
  • Les identités managées peuvent s’authentifier auprès des services et ressources Azure qui prennent en charge l’authentification Microsoft Entra ID. Cette méthode offre un moyen transparent et sécurisé de gérer les informations d’identification.
  • Pour plus d’informations sur l’utilisation de Identité managée avec Azure Communication Services, reportez-vous à ce guide.

• Principal du service :

  • Pour configurer un principal de service, créez une application inscrite à partir d’Azure CLI. Le point de terminaison et les informations d’identification peuvent ensuite être utilisés pour authentifier les Kits de développement logiciel (SDK).
  • Consultez des exemples d’utilisation du principal de service.

Communication Services prend en charge l’authentification Microsoft Entra ID pour les ressources Communication Services, tandis que vous pouvez continuer à utiliser l’autorisation de clé d’accès avec les applications de services de communication, Microsoft recommande de passer à Microsoft Entra ID dans le cas où cela est possible.

Utilisez notre Exemple de service d’authentification approuvé pour mapper des jetons d’accès Azure Communication Services à votre Microsoft Entra ID.

Jetons d’accès utilisateur

Les jetons d’accès utilisateur sont générés à l’aide du Kit de développement logiciel (SDK) Identity et associés aux utilisateurs créés dans ce Kit de développement logiciel (SDK) Identity. Consultez un exemple de création d'utilisateurs et de génération de jetons. Les jetons d’accès utilisateur sont ensuite utilisés pour authentifier les participants ajoutés aux conversations dans le kit de développement logiciel (SDK) de conversation ou d’appel. Pour plus d’informations, consultez Ajouter la conversation à votre application. L’authentification par jeton d’accès utilisateur est différente de l’authentification par clé d’accès et Microsoft Entra, car elle est utilisée pour authentifier un utilisateur plutôt qu’une ressource Azure sécurisée.

Utilisation de l’identité pour le monitoring et les métriques

L’identité de l’utilisateur est destinée à servir de clé primaire pour les journaux et les métriques collectés via Azure Monitor. Si vous souhaitez obtenir une vue de tous les appels d’un utilisateur spécifique, par exemple, vous devez configurer votre authentification de manière à mapper une ou plusieurs identités Azure Communication Services spécifiques à un utilisateur unique. Apprenez-en davantage sur Log Analytics et les métriques disponibles.

Étapes suivantes

Pour plus d’informations, consultez les articles suivants :

• En savoir plus sur l’architecture client et serveur