$ npm install @azure/identity
The Azure Identity library provides Azure Active Directory token authentication support across the Azure SDK. It provides a set of TokenCredential implementations which can be used to construct Azure SDK clients which support AAD token authentication.
You can find examples for these various credentials in the Azure Identity Examples Page
Key links:
Install Azure Identity with npm
:
npm install --save @azure/identity
This version of @azure/identity
supports stable (even numbered) versions of Node.js starting from v10. While it may run in Node.js v8, no support is guaranteed.
Note: If your application runs on Node.js v8 or lower, we strongly recommend you to upgrade your Node.js version to latest stable version or pin your
@azure/identity
dependency to version 1.1.0.
While we recommend using managed identity or service principal authentication in your production application, it is typical for a developer to use their own account for authenticating calls to Azure services when debugging and executing code locally. There are several developer tools which can be used to perform this authentication in your development environment.
Applications using the AzureCliCredential
, whether directly or via the DefaultAzureCredential
, can use the Azure CLI account to authenticate calls in the application when running locally.
To authenticate with the Azure CLI users can run the command az login
. For users running on a system with a default web browser the Azure cli will launch the browser to authenticate the user.
For systems without a default web browser, the az login
command will use the device code authentication flow. The user can also force the Azure CLI to use the device code flow rather than launching a browser by specifying the --use-device-code
argument.
Applications using the AzurePowerShellCredential
, whether directly or via the DefaultAzureCredential
, can use the account connected to Azure PowerShell to authenticate calls in the application when running locally.
To authenticate with Azure PowerShell users can run the Connect-AzAccount
cmdlet. By default, ike the Azure CLI, Connect-AzAccount
will launch the default web browser to authenticate a user account.
If interactive authentication cannot be supported in the session, then the -UseDeviceAuthentication
argument will force the cmdlet to use a device code authentication flow instead, similar to the corresponding option in the Azure CLI credential.
To authenticate Azure SDKs within web browsers, we currently offer the InteractiveBrowserCredential
, which can be set to use redirection or popups to complete the authentication flow. It is necessary to create an Azure App Registration in the portal for your web application first.
If this is your first time using @azure/identity
or the Microsoft identity platform (Azure Active Directory), we recommend that you read Using @azure/identity
with Microsoft Identity Platform first. This document will give you a deeper understanding of the platform and how to configure your Azure account correctly.
A credential is a class which contains or can obtain the data needed for a service client to authenticate requests. Service clients across Azure SDK accept credentials when they are constructed, and service clients use those credentials to authenticate requests to the service.
The Azure Identity library focuses on OAuth authentication with Azure Active directory, and it offers a variety of credential classes capable of acquiring an AAD token to authenticate service requests. All of the credential classes in this library are implementations of the TokenCredential abstract class, and any of them can be used by to construct service clients capable of authenticating with a TokenCredential.
See Credential Classes.
The DefaultAzureCredential
is appropriate for most scenarios where the application is intended to ultimately be run in the Azure Cloud. This is because the DefaultAzureCredential
combines credentials commonly used to authenticate when deployed with credentials used to authenticate in a development environment.
Note:
DefaultAzureCredential
is intended to simplify getting started with the SDK by handling common scenarios with reasonable default behaviors. Developers who want more control or whose scenario isn't served by the default settings should use other credential types.
If used from NodeJS, the DefaultAzureCredential
will attempt to authenticate via the following mechanisms in order:
DefaultAzureCredential
will read account information specified via environment variables and use it to authenticate.DefaultAzureCredential
will authenticate with that account.az login
command, the DefaultAzureCredential
will authenticate with that account.Connect-AzAccount
command, the DefaultAzureCredential
will authenticate with that account.Azure Identity for JavaScript provides an extension API that allows us to provide certain functionality through separate extension packages. The @azure/identity
package exports a top-level function (useIdentityExtension
) that can be used to enable an extension, and we provide two extension packages:
@azure/identity-cache-persistence
, which provides persistent token caching in Node.js using a native secure storage system provided by your operating system. This extension allows cached access_token
values to persist across sessions, meaning that an interactive login flow does not need to be repeated as long as a cached token is available.@azure/identity-vscode
, which provides the dependencies of VisualStudioCodeCredential
and enables it. Without this extension, the VisualStudioCodeCredential
in this package will throw a CredentialUnavailableError
. The extension provides the underlying implementation of this credential, enabling it for use both on its own and as part of the DefaultAzureCredential
described above.DefaultAzureCredential
and EnvironmentCredential
can be configured with environment variables. Each type of authentication requires values for specific variables:
variable name | value |
---|---|
AZURE_CLIENT_ID |
id of an Azure Active Directory application |
AZURE_TENANT_ID |
id of the application's Azure Active Directory tenant |
AZURE_CLIENT_SECRET |
one of the application's client secrets |
variable name | value |
---|---|
AZURE_CLIENT_ID |
id of an Azure Active Directory application |
AZURE_TENANT_ID |
id of the application's Azure Active Directory tenant |
AZURE_CLIENT_CERTIFICATE_PATH |
path to a PEM-encoded certificate file including private key (without password protection) |
variable name | value |
---|---|
AZURE_CLIENT_ID |
id of an Azure Active Directory application |
AZURE_USERNAME |
a username (usually an email address) |
AZURE_PASSWORD |
that user's password |
Configuration is attempted in the above order. For example, if values for a client secret and certificate are both present, the client secret will be used.
You can find more examples of using various credentials in Azure Identity Examples Page
DefaultAzureCredential
This example demonstrates authenticating the KeyClient
from the @azure/keyvault-keys client library using the DefaultAzureCredential
.
// The default credential first checks environment variables for configuration as described above.
// If environment configuration is incomplete, it will try managed identity.
// Azure Key Vault service to use
const { KeyClient } = require("@azure/keyvault-keys");
// Azure authentication library to access Azure Key Vault
const { DefaultAzureCredential } = require("@azure/identity");
// Azure SDK clients accept the credential as a parameter
const credential = new DefaultAzureCredential();
// Create authenticated client
const client = new KeyClient(vaultUrl, credential);
DefaultAzureCredential
A relatively common scenario involves authenticating using a user assigned managed identity for an Azure resource. Explore the example on Authenticating a user assigned managed identity with DefaultAzureCredential to see how this is made a relatively straightforward task that can be configured using environment variables or in code.
ChainedTokenCredential
While the DefaultAzureCredential
is generally the quickest way to get started developing applications for Azure, more advanced users may want to customize the credentials considered when authenticating. The ChainedTokenCredential
enables users to combine multiple credential instances to define a customized chain of credentials. This example demonstrates creating a ChainedTokenCredential
which will attempt to authenticate using two differently configured instances of ClientSecretCredential
, to then authenticate the KeyClient
from the @azure/keyvault-keys:
const { ClientSecretCredential, ChainedTokenCredential } = require("@azure/identity");
// When an access token is requested, the chain will try each
// credential in order, stopping when one provides a token
const firstCredential = new ClientSecretCredential(tenantId, clientId, clientSecret);
const secondCredential = new ClientSecretCredential(tenantId, anotherClientId, anotherSecret);
const credentialChain = new ChainedTokenCredential(firstCredential, secondCredential);
// The chain can be used anywhere a credential is required
const { KeyClient } = require("@azure/keyvault-keys");
const client = new KeyClient(vaultUrl, credentialChain);
The Managed identity authentication is supported via either the DefaultAzureCredential
or the ManagedIdentityCredential
credential classes directly for the following Azure hosts:
For examples of how to use managed identity for authentication please refer to the examples
credential | usage | example |
---|---|---|
DefaultAzureCredential |
Provides a simplified authentication experience to quickly start developing applications run in the Azure cloud. | example |
ChainedTokenCredential |
Allows users to define custom authentication flows composing multiple credentials. | example |
EnvironmentCredential |
Authenticates a service principal or user via credential information specified in environment variables. | example |
ManagedIdentityCredential |
Authenticates the managed identity of an Azure resource. | example |
credential | usage | example | reference |
---|---|---|---|
ClientSecretCredential |
Authenticates a service principal using a secret. | example | Service principal authentication |
ClientCertificateCredential |
Authenticates a service principal using a certificate. | example | Service principal authentication |
credential | usage | example | reference |
---|---|---|---|
InteractiveBrowserCredential |
Interactively authenticates a user with the default system browser. Read more about how this happens here. | example | OAuth2 authentication code |
DeviceCodeCredential |
Interactively authenticates a user on devices with limited UI. | example | Device code authentication |
UsernamePasswordCredential |
Authenticates a user with a username and password. | example | Username + password authentication |
AuthorizationCodeCredential |
Authenticate a user with a previously obtained authorization code. | example | OAuth2 authentication code |
credential | usage | example | reference |
---|---|---|---|
AzureCliCredential |
Authenticate in a development environment with the Azure CLI. | example | Azure CLI authentication |
AzurePowerShellCredential |
Authenticate in a development environment using Azure PowerShell. | example | Azure PowerShell authentication |
Credentials raise AuthenticationError
when they fail to authenticate. This class has a message
field which describes why authentication failed. An AggregateAuthenticationError
will be raised by ChainedTokenCredential
with an errors
field containing an array of errors from each credential in the chain.
Enabling logging may help uncover useful information about failures. In order to see a log of HTTP requests and responses, set the AZURE_LOG_LEVEL
environment variable to info
. Alternatively, logging can be enabled at runtime by calling setLogLevel
in the @azure/logger
:
import { setLogLevel } from "@azure/logger";
setLogLevel("info");
API documentation for this library can be found on our documentation site.
If you encounter bugs or have suggestions, please open an issue.
If you'd like to contribute to this library, please read the contributing guide to learn more about how to build and test the code.
© 2010 - cnpmjs.org x YWFE | Home | YWFE