| title | How to authenticate JavaScript apps with Azure services | ||
|---|---|---|---|
| description | Learn how to authenticate a JavaScript app with Azure services by using classes in the Azure Identity library. | ||
| ms.date | 02/18/2026 | ||
| ms.topic | concept-article | ||
| ms.custom |
|
Apps can use the Azure Identity library to authenticate to Microsoft Entra ID, which allows the apps to access Azure services and resources. This authentication requirement applies whether the app is deployed to Azure, hosted on-premises, or running locally on a developer workstation. The sections ahead describe the recommended approaches to authenticate an app to Microsoft Entra ID across different environments when using the Azure SDK for JavaScript.
Token-based authentication via Microsoft Entra ID is the recommended approach for authenticating apps to Azure, instead of using connection strings or key-based options. The Azure Identity library provides classes that support token-based authentication and allow apps to authenticate to Azure resources whether the app runs locally, on Azure, or on an on-premises server.
[!INCLUDE advantages of token-based authentication]
The specific type of token-based authentication an app should use to authenticate to Azure resources depends on where the app runs. The following diagram provides guidance for different scenarios and environments:
:::image type="content" source="../../../includes/authentication/media/mermaidjs/authentication-environments.svg" alt-text="A diagram showing the recommended token-based authentication strategies for an app depending on where it's running." :::
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 at authentication in server environments.
- Running locally during development: The app can authenticate to Azure using a developer account, a broker, or a service principal. Each option is discussed in more detail at authentication during local development.
- Hosted on-premises: The app should authenticate to Azure resources using an application service principal. On-premises workflows are discussed in more detail at Authentication for apps hosted on-premises.
When your app is hosted on Azure, it can use managed identities to authenticate to Azure resources without needing to manage any credentials. There are two types of managed identities: user-assigned and system-assigned.
A user-assigned managed identity is created as a standalone Azure resource. It can be assigned to one or more Azure resources, allowing those resources to share the same identity and permissions. To authenticate using a user-assigned managed identity, create the identity, assign it to your Azure resource, and then configure your app to use this identity for authentication by specifying its client ID.
[!div class="nextstepaction"] Authenticate using a user-assigned managed identity
A system-assigned managed identity is enabled directly on an Azure resource. The identity is tied to the lifecycle of that resource and is automatically deleted when the resource is deleted. To authenticate using a system-assigned managed identity, enable the identity on your Azure resource and then configure your app to use this identity for authentication.
[!div class="nextstepaction"] Authenticate using a system-assigned managed identity
During local development, you can authenticate to Azure resources using your developer credentials, a broker, or a service principal. This allows you to test your app's authentication logic without deploying it to Azure.
You can use your own Azure credentials to authenticate to Azure resources during local development. This is typically done using a development tool, such as Azure CLI, which can provide your app with the necessary tokens to access Azure services. This method is convenient but should only be used for development purposes.
[!div class="nextstepaction"] Authenticate locally using developer credentials
Brokered authentication collects user credentials using the system authentication broker to authenticate an app. A system authentication broker runs on a user's machine and manages the authentication handshakes and token maintenance for all connected accounts.
[!div class="nextstepaction"] Authenticate locally using a broker
A service principal is created in a Microsoft Entra tenant to represent an app and be used to authenticate to Azure resources. You can configure your app to use service principal credentials during local development. This method is more secure than using developer credentials and is closer to how your app will authenticate in production. However, it's still less ideal than using a managed identity due to the need for secrets.
[!div class="nextstepaction"] Authenticate locally using a service principal
For apps hosted on-premises, you can use a service principal to authenticate to Azure resources. This involves creating a service principal in Microsoft Entra ID, assigning it the necessary permissions, and configuring your app to use its credentials. This method allows your on-premises app to securely access Azure services.
[!div class="nextstepaction"] Authenticate your on-prem app using a service principal