当应用需要访问 Azure 资源时，应用必须向 Azure 进行身份验证。 对于所有应用（无论是部署到 Azure、本地部署还是在本地开发人员工作站上进行开发）都是如此。 本文介绍使用 Azure SDK 客户端库时向 Azure 验证应用的建议方法。
建议的应用身份验证方法
建议应用在向 Azure 资源进行身份验证时使用基于令牌的身份验证，而不是连接字符串。 Azure 标识库 提供了支持基于令牌的身份验证的类，并允许应用在本地开发、部署到 Azure 或部署到本地服务器时无缝地向 Azure 资源进行身份验证。
应用用于向 Azure 资源进行身份验证的特定类型取决于应用运行的位置，如下图所示：
当应用处于以下状态时：
- 在开发期间在本地运行时，应用使用用于本地开发的应用程序服务主体或使用开发人员的 Azure 凭据向 Azure 进行身份验证。 本地开发 期间，在身份验证中更详细地讨论了每个选项。
- 托管在 Azure上，应用应使用托管标识向 Azure 资源进行身份验证。 在服务器环境中进行身份验证中，对该选项进行更详细的讨论。
- 在本地托管和部署时，应用使用应用程序服务主体向 Azure 资源进行身份验证。 在服务器环境 中的身份验证中，将更详细地讨论此选项。
DefaultAzureCredential
Azure 标识库提供的 DefaultAzureCredential 类允许应用使用不同的身份验证方法，具体取决于它们的运行环境。 这样，应用就可以从本地开发升级到测试环境，而无需更改代码。 为每个环境配置适当的身份验证方法，DefaultAzureCredential 会自动检测和使用该身份验证方法。 应优先使用 DefaultAzureCredential，而不是手动编码条件逻辑或功能标志，以在不同的环境中使用不同的身份验证方法。
有关使用 DefaultAzureCredential 的详细信息，请参阅 在应用程序中使用 DefaultAzureCredential。
基于令牌的身份验证的优点
令牌验证相比于使用连接字符串进行身份验证，具有以下优势：
- 通过下面所述的基于令牌的身份验证方法，可以在 Azure 资源上建立应用所需的特定权限。 此方法遵循最低特权原则。 相比之下，连接字符串授予对 Azure 资源的完整权限。
- 而具有连接字符串的任何人或任何应用都可以连接到 Azure 资源，但基于令牌的身份验证方法将资源的访问范围限定为仅用于访问资源的应用（s）。
- 在使用托管标识的情况下，没有需要存储的应用程序密钥。 这使得应用更安全，因为没有可能会泄露的连接字符串或应用程序机密。
- Azure.Identity 包会为你获取和管理 Microsoft Entra 令牌。 这使得使用基于令牌的身份验证变得像连接字符串一样简单易用。
连接字符串的使用应仅限于无法访问生产或敏感数据的初始概念证明应用或开发原型。 否则，在向 Azure 资源进行身份验证时，Azure 标识库中提供的基于令牌的身份验证类应始终首选。
服务器环境中的身份验证
当在服务器环境中托管时，每个应用都会为应用运行的每个环境分配一个唯一的应用程序标识。 在 Azure 中，应用程序标识由 服务主体表示，这是一种特殊类型的 安全主体，旨在向 Azure 标识和验证应用。 要用于应用的服务主体的类型取决于应用正在运行的位置。
| 身份验证方法 | 描述 |
|---|---|
| 在 Azure 中托管的应用 | Azure 中托管的应用应该使用托管标识服务主体。 托管标识旨在表示 Azure 中托管的应用的标识，并且只能与 Azure 托管应用一起使用。 例如，在 Azure 应用服务中托管的 .NET Web 应用将分配托管标识。 然后，分配给应用的托管标识将用于向其他 Azure 服务对应用进行身份验证。 |
| 托管在 Azure 外部的应用 （例如，本地应用） |
需要连接到 Azure 服务的 Azure 外部（例如本地应用）托管的应用应使用 应用程序服务主体。 应用程序服务主体表示 Azure 中的应用标识，并通过应用程序注册过程创建。 例如，假设托管在本地的 .NET Web 应用使用 Azure Blob 存储。 使用应用注册过程为应用创建应用程序服务主体。 AZURE_CLIENT_ID、AZURE_TENANT_ID和 AZURE_CLIENT_SECRET 都存储为运行时应用程序要读取的环境变量，并允许应用使用应用程序服务主体向 Azure 进行身份验证。 |
在本地开发期间进行身份验证
在本地开发期间，当应用在本地开发期间在开发人员工作站上运行时，它仍必须向应用使用的任何 Azure 服务进行身份验证。 在本地开发期间将应用进行身份验证到 Azure 的两个主要策略包括：
| 身份验证方法 | 描述 |
|---|---|
| 创建在本地开发期间要使用的专用应用程序服务主体对象 | 在此方法中，专用 应用程序服务主体 对象是使用应用注册过程设置的，以便在本地开发期间使用。 然后，将服务主体的身份存储为环境变量，以便在本地开发环境中运行应用时访问。 此方法允许你将应用所需的特定资源权限分配给开发人员在本地开发期间使用的服务主体对象。 这可确保应用程序仅有权访问它所需的特定资源，并复制应用在生产环境中拥有的权限。 此方法的缺点是，需要为每个在应用程序上运行的开发人员创建单独的服务主体对象。 |
| 在本地开发期间，使用开发人员的凭据向 Azure 验证应用 | 在此方法中，开发人员必须从 Visual Studio、用于 VS Code 的 Azure 工具扩展、Azure CLI 或本地工作站上的 Azure PowerShell 登录到 Azure。 然后，应用程序可以从凭据存储访问开发人员的凭据，并使用这些凭据从应用访问 Azure 资源。 此方法具有更简单的设置优势，因为开发人员只需从 Visual Studio、VS Code 或 Azure CLI 登录到其 Azure 帐户。 此方法的缺点是，开发人员的帐户可能比应用程序所需的权限更多。 因此，此方法不会准确复制应用在生产环境中运行的权限。 |
在应用程序中使用 DefaultAzureCredential
DefaultAzureCredential 是用于对 Microsoft Entra ID 进行身份验证的有序机制序列。 每个身份验证机制都是派生自 TokenCredential 类的类，称为 凭据。 在运行时，DefaultAzureCredential 尝试使用第一个凭据进行身份验证。 如果该凭据无法获取访问令牌，则会尝试序列中的下一个凭据，依此方式，直到成功获取访问令牌。 这样，你的应用可以在不同的环境中使用不同的凭据，而无需编写特定于环境的代码。
若要使用 DefaultAzureCredential，请将 Azure.Identity 和 Microsoft.Extensions.Azure 包添加到应用程序：
在所选终端中，导航到应用程序项目目录并运行以下命令：
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure
Azure 服务使用各种 Azure SDK 客户端库中的专用客户端类进行访问。 应注册这些类和你自己的自定义服务，以便在整个应用中通过依赖项注入访问它们。 在 Program.cs 中，完成以下步骤以注册客户端类和 DefaultAzureCredential：
- 通过
using指令包括Azure.Identity和Microsoft.Extensions.Azure命名空间。 - 使用相应的
Add前缀扩展方法注册 Azure 服务客户端。 - 将
DefaultAzureCredential实例传递给UseCredential方法。
例如：
using Microsoft.Extensions.Azure;
using Azure.Identity;
builder.Services.AddAzureClients(clientBuilder =>
{
clientBuilder.AddBlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"));
clientBuilder.UseCredential(new DefaultAzureCredential());
});
UseCredential 的替代方法是直接实例化 DefaultAzureCredential：
using Azure.Identity;
builder.Services.AddSingleton<BlobServiceClient>(_ =>
new BlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"),
new DefaultAzureCredential()));
在本地开发工作站上运行上述代码时，它会在应用程序服务主体的环境变量或本地安装的开发人员工具（如 Visual Studio）中查找一组开发人员凭据。 两种方法都可用于在本地开发期间向 Azure 资源验证应用。
部署到 Azure 时，此相同的代码还可以向其他 Azure 资源验证应用。 DefaultAzureCredential 可以检索环境设置和托管标识配置，以便自动向其他服务进行身份验证。
