应用可以使用 Azure 标识库进行身份验证以Microsoft Entra ID，这允许应用访问 Azure 服务和资源。 此身份验证要求适用于应用是部署到 Azure、托管在本地还是在开发人员工作站本地运行。 接下来的部分将介绍在不同环境中使用 Azure SDK 客户端库时，通过 Microsoft Entra ID 对应用进行身份验证的推荐方法。
应用身份验证的建议方法
通过 Microsoft Entra ID 进行基于令牌的身份验证是向 Azure 进行身份验证的建议方法，而不是使用连接字符串或基于密钥的选项。 Azure 标识库提供支持基于令牌的身份验证的类，并允许应用在本地、Azure 或本地服务器上运行，对 Azure 资源进行身份验证。
基于令牌的身份验证的优点
基于令牌的身份验证在连接字符串方面具有以下优势：
- 基于令牌的身份验证可确保只有用于访问 Azure 资源的特定应用能够执行此作，而具有连接字符串的任何人或任何应用都可以连接到 Azure 资源。
- 通过基于令牌的身份验证，可以进一步限制 Azure 资源的访问，仅限于应用所需的特定权限。 此方法遵循最低特权原则。 相比之下，连接字符串授予对 Azure 资源的完整权限。
- 使用 托管标识 进行基于令牌的身份验证时，Azure 会为你处理管理功能，因此无需担心安全或轮换机密等任务。 这使得应用更安全，因为没有可能会泄露的连接字符串或应用程序机密。
- Azure 标识库会为你获取和管理Microsoft Entra 令牌。
连接字符串的使用应仅限于基于令牌的身份验证不是选项、初始概念证明应用或无法访问生产或敏感数据的开发原型的情况。 如果可能，请使用 Azure 标识库中提供的基于令牌的身份验证类向 Azure 资源进行身份验证。
跨不同环境进行身份验证
应用应用于对 Azure 资源进行身份验证的特定类型的基于令牌的身份验证取决于应用运行的位置。 下图提供了适用于不同方案和环境的指南：
当应用处于以下状态时：
- 托管在 Azure 上：应用应使用托管标识向 Azure 资源进行身份验证。 在服务器环境中进行身份验证中，对该选项进行更详细的讨论。
- 在开发期间本地运行：该应用可以通过应用服务主体进行本地开发身份验证，也可以使用开发人员的 Azure 凭据进行身份验证。 本地开发 期间，在身份验证中更详细地讨论了每个选项。
- 托管在本地：应用应使用应用程序服务主体或 Azure Arc 的托管标识向 Azure 资源进行身份验证。在 服务器环境中的身份验证中，更详细地讨论了本地工作流。
Azure 托管应用的身份验证
当应用托管在 Azure 上时，它可以使用托管标识向 Azure 资源进行身份验证，而无需管理任何凭据。 有两种类型的托管标识：用户分配和系统分配。
使用用户分配的托管标识
用户分配托管标识是作为独立的 Azure 资源创建的。 它可以分配给一个或多个 Azure 资源，从而允许这些资源共享相同的标识和权限。 若要使用用户分配的托管标识进行身份验证，请创建标识，将其分配给 Azure 资源，然后将应用配置为通过指定其客户端 ID、资源 ID 或对象 ID 来使用此标识进行身份验证。
使用系统分配的托管标识
系统分配托管标识直接在 Azure 资源上启用。 标识绑定到该资源的生命周期，并在删除资源时自动删除。 若要使用系统分配的托管标识进行身份验证，请在 Azure 资源上启用标识，然后将应用配置为使用此标识进行身份验证。
在本地开发期间进行身份验证
在本地开发期间，可以使用开发人员凭据或服务主体向 Azure 资源进行身份验证。 这样就可以测试应用的身份验证逻辑，而无需将其部署到 Azure。
使用开发人员凭据
可以在本地开发期间使用自己的 Azure 凭据向 Azure 资源进行身份验证。 这通常是使用开发工具（例如 Azure CLI 或 Visual Studio）完成的，它可以为应用提供访问 Azure 服务所需的令牌。 此方法很方便，但应仅用于开发目的。
使用服务主体
服务主体在 Microsoft Entra 租户中创建，用于表示应用，并用于向 Azure 资源进行身份验证。 可以将应用配置为在本地开发期间使用服务主体凭据。 此方法比使用开发人员凭据更安全，更接近应用在生产环境中进行身份验证的方式。 但是，由于需要机密，它仍然不如使用托管标识理想。
本地托管的应用的身份验证
对于本地托管的应用，可以使用服务主体对 Azure 资源进行身份验证。 这涉及到在 Microsoft Entra ID 中创建服务主体，为其分配必要的权限，以及配置应用以使用其凭据。 此方法允许本地应用安全地访问 Azure 服务。
