Authentifier des applications Java aux services Azure à l’aide de la bibliothèque Azure Identity

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. Cet article décrit les approches recommandées pour authentifier une application pour Microsoft Entra ID entre différents environnements lors de l’utilisation des bibliothèques clientes Azure SDK.

Approche recommandée pour l’authentification des applications

L’authentification basée sur les jetons via Microsoft Entra ID est l’approche recommandée pour authentifier les applications à Azure, au lieu d’utiliser des chaînes de connexion ou des options basées sur des clés. La bibliothèque d’identités Azure fournit des classes qui prennent en charge l’authentification basée sur des jetons et permettent aux applications de s’authentifier auprès de Azure ressources 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 y accéder, tandis que toute personne ou toute application disposant d’un connection string peut se connecter à une ressource Azure.
• L’authentification basée sur les jetons vous permet de limiter l’accès aux ressources Azure uniquement aux autorisations spécifiques requises par l’application. Cette approche suit le principe du privilège minimum. En revanche, une connection string accorde des droits complets à la ressource Azure.
• Lorsque vous utilisez une identité managed identity pour l'authentification basée sur les jetons, Azure gère les fonctions d'administration pour vous. Vous n'avez donc pas besoin de vous soucier des tâches telles que la sécurisation ou la rotation des secrets. Cette approche rend l'application plus sécurisée, car il n'existe aucune connection string ou secret d'application qui peut être compromis.
• 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 classes d’authentification basées sur des jetons disponibles dans la bibliothèque d’identités Azure pour s’authentifier auprès de Azure ressources.

Authentification dans différents environnements

Le type spécifique d’authentification basée sur les jetons qu’une application doit utiliser pour s’authentifier auprès de Azure ressources 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 :

• Hosted sur Azure : l’application doit s’authentifier auprès des ressources Azure à l’aide d’une identité managée. Pour plus d’informations, consultez la section Authentication pour les applications hébergées par Azure.
• Exécution locale pendant le développement : l’application peut s’authentifier auprès d'Azure à l'aide d'un developer account, d'un broker ou d'un service principal. Pour plus d’informations, consultez la section Authentification pendant le développement local .
• Hébergé sur site : 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 cadre de Azure Arc. Les flux de travail sur site sont abordés plus en détail dans Authentification pour les applications hébergées sur site.

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 de Azure ressources sans avoir à gérer les informations d’identification. Deux types d’identités managées sont disponibles : attribués par l’utilisateur et affectés par le système.

Utiliser une identité managée attribuée par l'utilisateur

Vous pouvez créer une identité managée affectée par l’utilisateur en tant que ressource Azure autonome. Vous pouvez ensuite l’affecter à une ou plusieurs ressources Azure afin que ces ressources puissent 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 pouvez activer 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 de Azure ressources à l’aide de vos informations d’identification de développeur, d’un répartiteur ou d’un principal de service. En utilisant l'une de ces méthodes, vous pouvez 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 de Azure ressources pendant le développement local. En règle générale, vous utilisez un outil de développement tel que Azure CLI, Azure CLI développeur, Azure PowerShell, Visual Studio Code ou IntelliJ IDEA. Ces outils peuvent fournir à votre application les jetons nécessaires pour accéder aux services Azure. Cette méthode est pratique, mais vous devez l’utiliser uniquement à 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

Vous pouvez créer un principal de service dans un locataire Microsoft Entra pour représenter une application et 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 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 de Azure ressources. 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.