Comment authentifier des applications JavaScript auprès des services Azure à l’aide du Kit de développement logiciel (SDK) Azure pour JavaScript

Article
05/02/2023

Lorsqu’une application doit accéder à une ressource Azure (par exemple, Stockage, Key Vault 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/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

Le processus recommandé consiste à utiliser l’authentification basée sur des jetons, plutôt que des chaîne de connexion ou des clés, lors de l’authentification auprès des ressources Azure. Le Kit de développement logiciel (SDK) 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 décrite plus en détail dans la section Authentification pendant le développement local.
Microsoft Azure	Quand 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 Authentification dans les environnements serveur.
Sur site	Quand 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 Authentification dans les environnements serveur.

Diagramme montrant les stratégies d’authentification par jeton recommandées pour une application en fonction de l’endroit où elle s’exécute.

Avantages de l’authentification par jeton

Lors de la création d’applications pour Azure, l’authentification basée sur les jetons est fortement recommandée sur les secrets (chaîne de connexion s ou clés). L’authentification basée sur les jetons est fournie avec DefaultAzureCredential.

Authentification basée sur un jeton	Secrets (chaîne de connexion s et clés)
Principe du privilège minimum, établissez les autorisations spécifiques nécessaires 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 faire pivoter les secrets dans le paramètre d’application ou la variable d’environnement.
Le Kit de développement logiciel (SDK) 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 des chaînes de connexion doit être limitée aux applications de preuve de concept initiales ou aux prototypes de développement qui n’accèdent pas aux données de production ou sensibles. Sinon, les classes d’authentification basées sur les jetons disponibles dans le SDK Azure doivent toujours être préférées lors de l’authentification auprès des ressources Azure.

Utilisez le Kit de développement logiciel (SDK) suivant :

@azure/identity

DefaultAzureCredential

La méthode DefaultAzureCredential du Kit de développement logiciel (SDK) Azure permet aux applications d’utiliser différentes méthodes d’authentification en fonction de l’environnement dans lequel elles sont exécutées. Cela permet aux applications de déployer dans des environnements locaux, de test et de production sans modification du code. Vous configurez la méthode d’authentification appropriée pour chaque environnement et DefaultAzureCredential détecte et utilise automatiquement cette méthode d’authentification. L’utilisation d’une logique conditionnelle ou d’indicateurs de fonctionnalités de codage manuel est préférable à l’utilisation de DefaultAzureCredential différentes méthodes d’authentification dans différents environnements.

Des détails sur l’utilisation de la classe DefaultAzureCredential sont abordés plus loin dans cet article de la section 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 de 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

Pour utiliser DefaultAzureCredential dans une application JavaScript, ajoutez le package @azure/identity à votre application.

npm install @azure/identity

Ensuite, l’exemple de code suivant montre comment instancier un DefaultAzureCredential objet et l’utiliser avec une classe cliente du Kit de développement logiciel (SDK) Azure, dans ce cas un BlobServiceClient utilisé pour accéder au stockage Blob.

// connect-with-default-azure-credential.js
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.

Séquence de sélection des méthodes d’authentification lors de l’utilisation de DefaultAzureCredential

En interne, DefaultAzureCredential implémente une chaîne de sélection de fournisseurs d’informations d’identification pour l’authentification d’applications auprès des ressources Azure. Chaque fournisseur d’informations d’identification est en mesure de détecter si les informations d’identification de ce type sont configurées pour l’application. DefaultAzureCredential vérifie séquentiellement chaque fournisseur dans l’ordre et utilise les informations d’identification du premier fournisseur sur lequel les informations d’identification sont configurées.

Si vous avez plusieurs informations d’identification configurées, l’ordre de recherche des informations d’identification par le biais de la chaîne est important.

L’ordre dans lequel DefaultAzureCredential recherche les informations d’identification pour JavaScript est illustré dans le diagramme et le tableau ci-dessous.

Il existe deux chemins :

Service déployé (Azure ou local) : la séquence commence par les variables d’environnement, puis l’identité managée, puis le reste des emplacements d’informations d’identification (Visual Studio Code, Azure CLI, Azure PowerShell).
Environnement local du développeur : la chaîne de station de travail du développeur local commence par l’utilisateur Azure connecté à Visual Studio Code, affichée dans la barre inférieure de l’IDE, puis passe à Azure CLI, puis à Azure PowerShell. Il est important de comprendre si vous avez configuré vos variables d’environnement locales, soit pour l’ensemble de votre environnement, soit pour l’environnement virtuel d’un projet (par exemple avec DOTENV), ces variables remplacent la chaîne Visual Studio Code -> Azure CLI -> PowerShell, car elles sont les premières informations d’identification case activée dans la chaîne.

Type d'informations d'identification	Description
Environnement	DefaultAzureCredential lit un ensemble de variables d’environnement pour déterminer si un principal de service d’application (utilisateur d’application) a été défini pour l’application. Si c’est le cas, `DefaultAzureCredential` utilise ces valeurs pour authentifier l’application auprès d’Azure. Cette méthode est le plus souvent utilisée dans les environnements serveur, mais peut également être utilisée lors du développement local.
Identité managée	Si l’application est déployée sur un hôte Azure avec l’identité managée activée, `DefaultAzureCredential` authentifie l’application auprès d’Azure à l’aide de cette identité managée. L’authentification à l’aide d’une identité managée est décrite dans la section Authentification dans les environnements serveur de ce document. Cette méthode est disponible uniquement lorsqu’une application est hébergée dans Azure à l’aide d’un service avec identité managée.
Visual Studio Code	Si le développeur s’est authentifié auprès d’Azure à l’aide du plug-in de compte Azure Visual Studio Code, `DefaultAzureCredential` authentifie l’application auprès d’Azure à l’aide de ce même compte.
Azure CLI	Si un développeur s’est authentifié auprès d’Azure à l’aide de la commande `az login` dans Azure CLI, `DefaultAzureCredential` authentifie l’application auprès d’Azure à l’aide de ce même compte.
Azure PowerShell	Si un développeur s’est authentifié auprès d’Azure à l’aide de la cmdlet Azure PowerShell `Connect-AzAccount`, `DefaultAzureCredential` authentifie l’application auprès d’Azure à l’aide de ce même compte.
Interactif	Si cette option est activée, DefaultAzureCredential authentifie de manière interactive le développeur via le navigateur par défaut du système actuel. Par défaut, cette option est désactivée.

Partager via