How to authenticate JavaScript apps to Azure services using the Azure Identity library

When an application needs to access an Azure resource, such as Storage, Key Vault, or Cognitive Services, the application must be authenticated to Azure. This is true for all applications, whether deployed to Azure, deployed on-premises, or under development on a local developer workstation. This article describes the recommended approaches to authenticate an app to Azure when using the Azure SDK for JavaScript.

Recommended app authentication approach

The recommended approach is to have your apps use token-based authentication, rather than connection strings or keys, when authenticating to Azure resources. The Azure Identity library provides token-based authentication and allows apps to seamlessly authenticate to Azure resources whether the app is in local development, deployed to Azure, or deployed to an on-premises server.

The specific type of token-based authentication an app should use to authenticate to Azure resources depends on where the app is running and is shown in the following diagram.

Environment	Authentication
Local	When a developer is running an app during local development - The app can authenticate to Azure using either an application service principal for local development or by using the developer's Azure credentials. Each of these options is discussed in more detail in the section authentication during local development.
Azure	When an app is hosted on Azure - The app should authenticate to Azure resources using a managed identity. This option is discussed in more detail below in the section authentication in server environments.
On-premises	When an app is hosted and deployed on-premises - The app should authenticate to Azure resources using an application service principal. This option is discussed in more detail below in the section authentication in server environments.

Advantages of token-based authentication

When building apps for Azure, token-based authentication is strongly recommended over secrets (connection strings or keys). Token-based authentication is provided with DefaultAzureCredential.

Token-based authentication	Secrets (connection strings and keys)
Principle of least privilege, establish the specific permissions needed by the app on the Azure resource.	A connection string or key grants full rights to the Azure resource.
There's no application secret to store.	Must store and rotate secrets in app setting or environment variable.
The Azure Identity library manages tokens for you behind the scenes. This makes using token-based authentication as easy to use as a connection string.	Secrets aren't managed.

Use of connection strings should be limited to initial proof of concept apps or development prototypes that don't access production or sensitive data. Otherwise, the token-based authentication classes available in the Azure Identity library should always be preferred when authenticating to Azure resources.

Use the following library:

• @azure/identity

DefaultAzureCredential

The DefaultAzureCredential class provided by the Azure Identity library allows apps to use different authentication methods depending on the environment in which they're run. This behavior allows apps to be promoted from local development to test environments to production without code changes. You configure the appropriate authentication method for each environment, and DefaultAzureCredential will automatically detect and use that authentication method. The use of DefaultAzureCredential should be preferred over manually coding conditional logic or feature flags to use different authentication methods in different environments.

Details about using DefaultAzureCredential are covered at Use DefaultAzureCredential in an application.

Authentication in server environments

When hosting in a server environment, each application should be assigned a unique application identity per environment. In Azure, an app identity is represented by a service principal, a special type of security principal intended to identify and authenticate apps to Azure. The type of service principal to use for your app depends on where your app is running.

Authentication during local development

When an application is run on a developer's workstation during local development, the local environment must still authenticate to any Azure services used by the app.

Use DefaultAzureCredential in an application

DefaultAzureCredential is an opinionated, ordered sequence of mechanisms for authenticating to Microsoft Entra ID. Each authentication mechanism is a class derived from the TokenCredential class and is known as a credential. At runtime, DefaultAzureCredential attempts to authenticate using the first credential. If that credential fails to acquire an access token, the next credential in the sequence is attempted, and so on, until an access token is successfully obtained. In this way, your app can use different credentials in different environments without writing environment-specific code.

To use DefaultAzureCredential, add the @azure/identity package to your application.

npm install @azure/identity

Then, the following code sample shows how to instantiate a DefaultAzureCredential object and use it with an Azure SDK service client class—in this case, a BlobServiceClient used to access Azure Blob Storage.

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 will automatically detect the authentication mechanism configured for the app and obtain the necessary tokens to authenticate the app to Azure. If an application makes use of more than one SDK client, the same credential object can be used with each SDK client object.