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, qui accorde l’accès 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 suivantes 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. Le module client Azure Identity pour Go fournit une authentification basée sur des jetons et permet 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 les jetons garantit que seules les applications spécifiques destinées à accéder à la ressource Azure peuvent 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 privilège minimum. 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. Cette fonctionnalité rend l’application plus sécurisée, car il n’existe aucune chaîne de connexion ni secret d’application pouvant être compromis.
- Les chaînes de connexion sont fonctionnellement équivalentes aux informations d’identification et nécessitent une gestion spéciale pour empêcher les fuites accidentelles. Vous devez les stocker en toute sécurité (par exemple, dans Azure Key Vault) et ne jamais les encoder en dur dans votre application ou les valider dans le contrôle de code source. Microsoft Secure Future Initiative (SFI) interdit l’utilisation de chaînes de connexion et de secrets de longue durée similaires, car ils peuvent être utilisés pour compromettre votre application s’ils ne sont pas gérés avec soin.
- La bibliothèque d’identités Azure acquiert et gère les jetons Microsoft Entra pour vous.
Limitez l’utilisation des chaînes de connexion 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 types d’informations d’identification dans la bibliothèque d’identités Azure pour vous authentifier auprès des ressources Azure.
Authentification dans différents environnements
Le type d’authentification basée sur les jetons qu’une application utilise 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. Pour plus d’informations, consultez 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 principal de service d’application pour le développement local ou des informations d’identification Azure du développeur. Pour plus d’informations, consultez l’authentification pendant le 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, dans le cas d’Azure Arc, d’une identité managée. Pour plus d’informations, consultez l’authentification dans les environnements serveur.
Authentification pour les applications hébergées par Azure
Lorsque vous hébergez votre application 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
Vous créez une identité managée affectée par l’utilisateur en tant que ressource Azure autonome. Vous pouvez l’affecter à une ou plusieurs ressources Azure, ce qui permet à ces ressources de partager la même identité et les mêmes 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 utiliser cette identité 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
Vous activez une identité managée affectée par le système 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. Cette méthode d’authentification 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. En règle générale, vous utilisez un outil de développement, tel qu’Azure CLI, 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 principal de service
Vous créez un principal de service dans un locataire Microsoft Entra pour représenter une application et l’utiliser pour vous 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 encore 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. Cette méthode 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. Avec cette méthode, votre application locale peut accéder en toute sécurité aux services Azure.