Comment authentifier des applications JavaScript auprès des services Azure à l’aide de la bibliothèque d’identités Azure
Lorsqu’une application doit accéder à une ressource Azure, telle que stockage, coffre de clés ou Cognitive Services, l’application doit être authentifiée auprès d’Azure. Cela est vrai pour toutes les applications, qu’elles soient déployées sur Azure, déployées localement ou en cours de développement sur une station de travail de développeur locale. Cet article décrit les approches recommandées pour authentifier une application auprès d’Azure lors de l’utilisation du Kit de développement logiciel (SDK) Azure pour JavaScript.
Approche d’authentification d’application recommandée
L’approche recommandée consiste à faire en sorte que vos applications utilisent l’authentification basée sur un jeton, plutôt que des chaînes de connexion ou des clés, lors de l’authentification auprès des ressources Azure. La bibliothèque d’identités Azure fournit une authentification basée sur des jetons et permet aux applications de s’authentifier en toute transparence auprès des ressources Azure, que l’application soit en développement local, déployée sur Azure ou déployée sur un serveur local.
Le type spécifique d’authentification basée sur les 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 et est illustré dans le diagramme suivant.
| Environnement | Authentification |
|---|---|
| Local | Lorsqu’un développeur exécute une application pendant le développement local : l’application peut s’authentifier auprès d’Azure à l’aide d’un principal de service d’application pour le développement local ou à l’aide des informations d’identification Azure du développeur. Chacune de ces options est abordée plus en détail dans la section l’authentification pendant le développement local. |
| Azure | Lorsqu’une application est hébergée 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 ci-dessous dans la section l’authentification dans les environnements serveur. |
| Local | Lorsqu’une application est hébergée et déployée localement : l’application doit s’authentifier auprès des ressources Azure à l’aide d’un principal de service d’application. Cette option est décrite plus en détail ci-dessous dans la section l’authentification dans les environnements serveur. |
Avantages de l’authentification basée sur les jetons
Lors de la création d’applications pour Azure, l’authentification basée sur les jetons est fortement recommandée sur les secrets (chaînes de connexion ou clés). L’authentification basée sur les jetons est fournie avec DefaultAzureCredential .
| Authentification basée sur les jetons | Secrets (chaînes de connexion et clés) |
|---|---|
| Principe du privilège minimum, établissez les autorisations spécifiques requises par l’application sur la ressource Azure. | Une chaîne de connexion ou une clé accorde des droits complets à la ressource Azure. |
| Il n’existe aucun secret d’application à stocker. | Doit stocker et alterner les secrets dans le paramètre d’application ou la variable d’environnement. |
| La bibliothèque Azure Identity gère les jetons pour vous en arrière-plan. Cela permet d’utiliser l’authentification basée sur des jetons aussi facile à utiliser qu’une chaîne de connexion. | Les secrets ne sont pas gérés. |
L'utilisation de chaînes de connexion doit être limitée aux preuves de concept initiales ou aux prototypes de développement qui n'accèdent pas aux données de production ou sensibles. Dans le cas contraire, les classes d’authentification basées sur les jetons disponibles dans la bibliothèque d’identités Azure doivent toujours être préférées lors de l’authentification auprès des ressources Azure.
Utilisez la bibliothèque suivante :
DefaultAzureCredential
La classe DefaultAzureCredential fournie par la bibliothèque d’identités Azure permet aux applications d’utiliser différentes méthodes d’authentification en fonction de l’environnement dans lequel elles sont exécutées. Ce comportement permet aux applications d’être promues du développement local aux environnements de test vers la production sans modification du code. Vous configurez la méthode d’authentification appropriée pour chaque environnement, et DefaultAzureCredential détectera et utilisera automatiquement cette méthode d’authentification. L’utilisation de DefaultAzureCredential doit être préférée au codage manuel de la logique conditionnelle ou des indicateurs de fonctionnalités pour utiliser différentes méthodes d’authentification dans différents environnements.
Des détails sur l’utilisation de DefaultAzureCredential sont abordés dans Utiliser DefaultAzureCredential dans une application.
Authentification dans les environnements serveur
Lors de l’hébergement dans un environnement serveur, chaque application doit recevoir une identité d’application unique par environnement. Dans Azure, une identité d’application est représentée par un principal de service , un type spécial d'principal de sécurité destiné à identifier et authentifier les applications auprès d’Azure. Le type de principal de service à utiliser pour votre application dépend de l’emplacement d’exécution de votre application.
Authentification pendant le développement local
Lorsqu’une application est exécutée sur la station de travail d’un développeur pendant le développement local, l’environnement local doit toujours s’authentifier auprès des services Azure utilisés par l’application.
Utiliser DefaultAzureCredential dans une application
DefaultAzureCredential est une séquence ordonnée et fondée d’authentification auprès de Microsoft Entra ID. Chaque mécanisme d’authentification est une classe dérivée de la classe TokenCredential et est appelé . Au moment de l’exécution, DefaultAzureCredential tente de s’authentifier à l’aide du premier identifiant. Si ces informations d’identification ne parvient pas à acquérir un jeton d’accès, les informations d’identification suivantes de la séquence sont tentées, et ainsi de suite, jusqu’à ce qu’un jeton d’accès soit obtenu avec succès. De cette façon, votre application peut utiliser différentes informations d’identification dans différents environnements sans écrire de code spécifique à l’environnement.
Pour utiliser DefaultAzureCredential, ajoutez le package @azure/identity à votre application.
npm install @azure/identity
Ensuite, l’exemple de code suivant montre comment instancier un objet DefaultAzureCredential et l’utiliser avec une classe cliente du service sdk Azure, dans ce cas, un BlobServiceClient utilisé pour accéder au Stockage Blob Azure.
import { BlobServiceClient } from '@azure/storage-blob';
import { DefaultAzureCredential } from '@azure/identity';
import 'dotenv/config';
const accountName = process.env.AZURE_STORAGE_ACCOUNT_NAME;
if (!accountName) throw Error('Azure Storage accountName not found');
const blobServiceClient = new BlobServiceClient(
`https://${accountName}.blob.core.windows.net`,
new DefaultAzureCredential()
);
DefaultAzureCredential détecte automatiquement le mécanisme d’authentification configuré pour l’application et obtient les jetons nécessaires pour authentifier l’application auprès d’Azure. Si une application utilise plusieurs clients sdk, le même objet d’informations d’identification peut être utilisé avec chaque objet client sdk.