如何使用适用于 JavaScript 的 Azure SDK 向 Azure 服务验证 JavaScript 应用

项目
10/21/2023

当应用程序需要访问 Azure 资源（例如存储、密钥保管库或认知服务）时，应用程序必须向 Azure 进行身份验证。这适用于所有应用程序，不管它们是部署到 Azure、部署在本地，还是仍在本地开发人员工作站上处于开发中状态。本文介绍使用适用于 JavaScript 的 Azure SDK 时向 Azure 验证应用的建议方法。

建议的应用身份验证方法

建议的过程是让应用在向 Azure 资源进行身份验证时使用基于令牌的身份验证，而不是连接字符串或密钥。 Azure SDK 提供基于令牌的身份验证，并允许应用在本地开发、部署到 Azure 或部署到本地服务器的情况下无缝地向 Azure 资源进行身份验证。

应用用于对 Azure 资源进行身份验证的特定类型的基于令牌的身份验证取决于应用正在运行的位置，如下图所示。

环境	身份验证
本地	当开发人员在本地开发期间运行应用时 - 该应用可以使用用于本地开发的应用程序服务主体或使用开发人员的 Azure 凭据向 Azure 进行身份验证。在本地开发期间进行身份验证部分更详细地介绍了其中的每个选项。
Azure	当应用托管在 Azure 上时 - 该应用应该使用托管标识向 Azure 资源进行身份验证。下面的在服务器环境中进行身份验证部分更详细地介绍了此选项。
本地	当应用托管并部署在本地时 - 该应用应该使用应用程序服务主体向 Azure 资源进行身份验证。下面的在服务器环境中进行身份验证部分更详细地介绍了此选项。

该图显示应用的建议基于令牌的身份验证策略取决于其运行位置。

基于令牌的身份验证的优势

为 Azure 生成应用时，强烈建议使用基于令牌的身份验证（连接字符串或密钥）。基于令牌的身份验证随 DefaultAzureCredential 一起提供。

基于令牌的身份验证	机密（连接字符串和密钥）
最低特权原则，在 Azure 资源上建立应用所需的特定权限。	连接字符串或密钥授予对 Azure 资源的完整权限。
没有要存储的应用程序机密。	必须在应用设置或环境变量中存储和轮换机密。
Azure 标识 SDK 在后台为你管理令牌。这使得使用基于令牌的身份验证与连接字符串一样易于使用。	机密不受管理。

应该仅限不访问生产数据或敏感数据的初始概念证明应用或开发原型使用连接字符串。否则，在向 Azure 资源进行身份验证时，应始终优先使用 Azure SDK 中提供的基于令牌的身份验证类。

使用以下 SDK：

@azure/identity

DefaultAzureCredential

Azure SDK DefaultAzureCredential 方法允许应用根据运行环境使用不同的身份验证方法。这样，应用就可以在本地、测试和生产环境中部署，而无需更改代码。为每个环境配置适当的身份验证方法，并 DefaultAzureCredential 自动检测和使用该身份验证方法。最好使用 DefaultAzureCredential 手动编码条件逻辑或功能标志，以在不同的环境中使用不同的身份验证方法。

有关使用 DefaultAzureCredential 类的详细信息，请参阅本文后面的“在应用程序中使用 DefaultAzureCredential”部分。

在服务器环境中进行身份验证

在服务器环境中托管时，每个应用程序应为每个环境分配唯 一的应用程序标识 。在 Azure 中，应用标识由服务主体表示，这是一种特殊类型的安全主体，旨在标识该应用以及在 Azure 中对其进行身份验证。要为应用使用的服务主体类型取决于应用的运行位置。

在本地开发期间进行身份验证

在本地开发期间，在开发人员工作站上运行应用程序时，本地环境仍必须向应用使用的任何 Azure 服务进行身份验证。

在应用程序中使用 DefaultAzureCredential

若要在 JavaScript 应用中使用 DefaultAzureCredential ，请将 @azure/标识包添加到应用程序。

npm install @azure/identity

然后，下面的代码示例演示如何实例化对象 DefaultAzureCredential 并将其用于 Azure SDK 客户端类，在本例中为用于访问 Blob 存储的 BlobServiceClient。

// 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 将自动检测为应用配置的身份验证机制，并获取必要的令牌，以便向 Azure 对应用进行身份验证。如果应用程序使用多个 SDK 客户端，则同一凭据对象可与每个 SDK 客户端对象一起使用。

使用 DefaultAzureCredential 时选择身份验证方法的顺序

在内部， DefaultAzureCredential 实现一系列选择凭据提供程序，以便将应用程序进行身份验证到 Azure 资源。每个凭据提供程序能够检测是否为应用配置了这种类型的凭据。 DefaultAzureCredential 按顺序检查每个提供程序，并使用第一个配置了凭据的提供程序的凭据。

如果已配置多个凭据，则通过链查找凭据的顺序非常重要。

下图和下表显示了查找 JavaScript 凭据的顺序 DefaultAzureCredential 。

有两个路径：

部署的服务 （Azure 或本地）：序列以环境变量开始，然后是托管标识，然后是凭据的其余位置（Visual Studio Code、Azure CLI、Azure PowerShell）。
开发人员的本地环境：本地开发人员工作站的链以 Visual Studio Code 的登录 Azure 用户开头，显示在 IDE 的底部栏中，然后转到 Azure CLI，然后转到 Azure PowerShell。请务必了解是否已为整个环境或项目的虚拟环境（如 DOTENV）配置了本地环境变量，这些变量将替代 Visual Studio Code - Azure CLI ->> PowerShell 链，因为它们是链中检查的第一个凭据。

凭据类型	说明
环境	DefaultAzureCredential 读取一组环境变量，以确定是否已为应用设置应用程序服务主体（应用程序用户）。如果是，则 `DefaultAzureCredential` 将使用这些值对访问 Azure 的应用进行身份验证。此方法最常用于服务器环境，但也可以在进行本地开发时使用。
托管标识	如果应用程序已部署到启用了托管标识的 Azure 主机，则 `DefaultAzureCredential` 将使用该托管标识对访问 Azure 的应用进行身份验证。本文档的在服务器环境中进行身份验证部分介绍了如何使用托管标识进行身份验证。仅当使用启用了托管标识的服务在 Azure 中托管应用程序时，此方法才可用。
Visual Studio Code	如果开发人员已使用 Visual Studio Code Azure 帐户插件向 Azure 进行身份验证，则 `DefaultAzureCredential` 将使用同一帐户对访问 Azure 的应用进行身份验证。
Azure CLI	如果开发人员已在 Azure CLI 中使用 `az login` 命令向 Azure 进行身份验证，则 `DefaultAzureCredential` 将使用同一帐户对访问 Azure 的应用进行身份验证。
Azure PowerShell	如果开发人员已在 Azure PowerShell 中使用 `Connect-AzAccount` cmdlet 向 Azure 进行身份验证，则 `DefaultAzureCredential` 将使用同一帐户对访问 Azure 的应用进行身份验证。
交互	如果启用，DefaultAzureCredential 将通过当前系统的默认浏览器以交互方式对开发人员进行身份验证。默认情况下禁用此选项。

通过