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.
Les applications peuvent utiliser la bibliothèque d’identités Azure pour s’authentifier auprès de Microsoft Entra ID, ce qui permet aux applications d’accéder aux services et ressources Azure. Cette exigence d’authentification s’applique si l’application est déployée sur Azure, hébergée localement ou exécutée localement sur une station de travail de développeur. Les sections qui suivent décrivent les approches recommandées pour authentifier une application auprès de Microsoft Entra ID dans différents environnements lors de l’utilisation des bibliothèques clientes du Kit de développement logiciel (SDK) Azure.
Approche recommandée pour l’authentification des applications
L’authentification basée sur les jetons via l’ID Microsoft Entra est l’approche recommandée pour l’authentification des applications auprès d’Azure, au lieu d’utiliser des chaînes de connexion ou des options basées sur des clés. La bibliothèque Azure Identity fournit des classes qui prennent en charge l’authentification basée sur des jetons et permettent aux applications de s’authentifier auprès des ressources Azure, que l’application s’exécute localement, sur Azure ou sur un serveur local.
Avantages de l'authentification par jeton
L’authentification basée sur des jetons offre les avantages suivants par rapport aux chaînes de connexion :
- L’authentification basée sur un jeton garantit que seules les applications spécifiques destinées à accéder à la ressource Azure sont en mesure de le faire, tandis que toute personne ou toute application disposant d’une chaîne de connexion peut se connecter à une ressource Azure.
- L’authentification basée sur les jetons vous permet de limiter davantage l’accès aux ressources Azure aux seules autorisations spécifiques nécessaires par l’application. Cette approche suit le principe du moindre privilège. En revanche, une chaîne de connexion accorde des droits complets à la ressource Azure.
- Lorsque vous utilisez une identité managée pour l’authentification basée sur des jetons, Azure gère les fonctions d’administration pour vous. Vous n’avez donc pas à vous soucier des tâches telles que la sécurisation ou la rotation des secrets. L'application est donc plus sûre, car il n'y a pas de chaîne de connexion ou de secret d'application susceptible d'être compromis.
- La bibliothèque d’identités Azure acquiert et gère les jetons Microsoft Entra pour vous.
L’utilisation de chaînes de connexion doit être limitée aux scénarios où l’authentification basée sur des jetons n’est pas une option, des applications de preuve de concept initiales ou des prototypes de développement qui n’accèdent pas à la production ou aux données sensibles. Si possible, utilisez les classes d’authentification basées sur des jetons disponibles dans la bibliothèque Azure Identity pour s’authentifier auprès des ressources Azure.
Authentification dans différents environnements
Le type spécifique d’authentification basée sur des jetons qu’une application doit utiliser pour s’authentifier auprès des ressources Azure dépend de l’emplacement d’exécution de l’application. Le diagramme suivant fournit des conseils pour différents scénarios et environnements :
Lorsqu'une application est :
- Hébergé sur Azure : l’application doit s’authentifier auprès des ressources Azure à l’aide d’une identité managée. Cette option est décrite plus en détail dans l’authentification dans les environnements serveur.
- En cours d’exécution localement pendant le développement : l’application peut s’authentifier auprès d’Azure à l’aide d’un compte de développeur, d’un répartiteur ou d’un principal de service. Chaque option est discutée plus en détail lors de l'authentification au cours du développement local.
- Hébergé localement : l’application doit s’authentifier auprès des ressources Azure à l’aide d’un principal de service d’application ou d’une identité managée dans le cas d’Azure Arc. Les flux de travail locaux sont abordés plus en détail sur l’authentification pour les applications hébergées localement.
Authentification pour les applications hébergées par Azure
Lorsque votre application est hébergée sur Azure, elle peut utiliser des identités managées pour s’authentifier auprès des ressources Azure sans avoir à gérer les informations d’identification. Il existe deux types d’identités managées : attribuées par l’utilisateur et affectées par le système.
Utiliser une identité managée affectée par l’utilisateur
Une identité managée attribuée par l’utilisateur est créée en tant que ressource Azure autonome. Il peut être affecté à une ou plusieurs ressources Azure, ce qui permet à ces ressources de partager les mêmes identités et autorisations. Pour vous authentifier à l’aide d’une identité managée affectée par l’utilisateur, créez-la, affectez-la à votre ressource Azure, puis configurez votre application pour l’utiliser pour l’authentification en spécifiant son ID client, son ID de ressource ou son ID d’objet.
Utiliser une identité managée affectée par le système
Une identité managée attribuée par le système est activée directement sur une ressource Azure. L’identité est liée au cycle de vie de cette ressource et est automatiquement supprimée lorsque la ressource est supprimée. Pour vous authentifier à l’aide d’une identité managée affectée par le système, activez l’identité sur votre ressource Azure, puis configurez votre application pour utiliser cette identité pour l’authentification.
Authentification pendant le développement local
Pendant le développement local, vous pouvez vous authentifier auprès des ressources Azure à l’aide de vos informations d’identification de développeur ou d’un principal de service. Cela vous permet de tester la logique d’authentification de votre application sans la déployer sur Azure.
Utiliser les informations d’identification du développeur
Vous pouvez utiliser vos propres informations d’identification Azure pour vous authentifier auprès des ressources Azure pendant le développement local. Cette opération est généralement effectuée à l’aide d’un outil de développement, tel qu’Azure CLI ou Visual Studio, qui peut fournir à votre application les jetons nécessaires pour accéder aux services Azure. Cette méthode est pratique, mais ne doit être utilisée qu’à des fins de développement.
Utiliser un répartiteur
L’authentification répartie collecte les informations d’identification de l’utilisateur à l’aide du répartiteur d’authentification système pour authentifier une application. Un courtier d’authentification système s’exécute sur l’ordinateur d’un utilisateur et gère les échanges d’authentification et la maintenance des jetons pour tous les comptes connectés.
Utiliser un principal de service
Un principal de service est créé dans un locataire Microsoft Entra pour représenter une application et être utilisé pour s’authentifier auprès des ressources Azure. Vous pouvez configurer votre application pour utiliser les informations d’identification du principal de service pendant le développement local. Cette méthode est plus sécurisée que l’utilisation des informations d’identification du développeur et est plus proche de la façon dont votre application s’authentifie en production. Toutefois, il est toujours moins idéal que d’utiliser une identité managée en raison de la nécessité de secrets.
Authentification pour les applications hébergées localement
Pour les applications hébergées localement, vous pouvez utiliser un principal de service pour vous authentifier auprès des ressources Azure. Cela implique la création d’un principal de service dans Microsoft Entra ID, l’affectation des autorisations nécessaires et la configuration de votre application pour utiliser ses informations d’identification. Cette méthode permet à votre application locale d’accéder en toute sécurité aux services Azure.