将应用服务或 Azure Functions 应用配置为使用 Microsoft Entra 登录

选择另一个身份验证提供商以跳转到它。

本文介绍如何为 Azure 应用服务或 Azure Functions 配置身份验证，使应用使用 Microsoft 标识平台 (Microsoft Entra) 作为身份验证提供程序让用户登录。

为应用程序及其用户选择租户

在应用程序可以让用户登录之前，首先需要在员工租户或外部租户中注册应用。 如果使应用可供员工或业务来宾使用，请在员工租户中注册应用。 如果应用供消费者和企业客户使用，请在外部租户中注册应用。

1. 登录 Azure 门户并导航到你的应用程序。

2. 在应用程序的左侧菜单中，选择“身份验证”，然后选择“添加标识提供者”。

3. 在“添加标识提供者”页上，选择“Microsoft”作为“标识提供者”以登录 Microsoft 和 Microsoft Entra 标识。

4. 对于“租户类型”，请为员工和业务来宾选择“员工配置（当前租户）”，或为消费者和企业客户选择“外部配置”。

选择应用注册

应用服务身份验证功能可以自动为你创建应用注册，也可以使用你或目录管理员单独创建的注册。

自动创建新的应用注册，除非需要单独创建应用注册。 如果需要，可以稍后在 Microsoft Entra 管理中心中自定义应用注册。

以下情况是使用现有应用注册的最常见情况：

• 你的帐户无权在 Microsoft Entra 租户中创建应用注册。
• 你想要使用的应用注册来自其他 Microsoft Entra 租户，而不是应用所在的租户。

配置其他检查

配置其他检查，确定允许哪些请求访问应用程序。 你现在可以自定义此行为，也可以稍后通过选择“身份验证”设置旁边的“编辑”，在主要“身份验证”屏幕上调整这些设置。

对于客户端应用程序要求，请选择是否：

• 仅允许来自此应用程序本身的请求
• 允许来自特定客户端应用程序的请求
• 允许来自任何应用程序的请求（不建议）

对于标识要求，请选择是否：

• 允许来自任何标识的请求
• 允许来自特定标识的请求

对于租户要求，请选择是否：

• 仅允许来自证书颁发者租户的请求
• 允许来自特定租户的请求
• 根据证书颁发者使用默认限制

你的应用可能需要在代码中做出额外的授权决策。 有关详细信息，请参阅“使用内置授权策略”。

配置身份验证设置

这些选项可确定应用程序如何响应未经身份验证的请求，默认选择会将所有请求重定向到用此新提供程序登录。 你现在可以更改自定义此行为，也可以稍后通过选择“身份验证”设置旁边的“编辑”，在主要“身份验证”屏幕上调整这些设置。 若要详细了解这些选项，请参阅身份验证流。

对于 限制访问，请决定是否：

• 需要身份验证
• 允许未经身份验证的访问

对于未经身份验证的请求

• HTTP 302 发现重定向：建议用于网站
• HTTP 401 未授权：建议用于 API
• HTTP 403 禁止访问
• HTTP 404 找不到

选择“令牌存储”（建议）。 令牌存储收集、存储和刷新应用程序的令牌。 如果应用不需要令牌，或者需要优化性能，则可以稍后禁用此功能。

添加标识提供者

如果选择了员工配置，则可以选择“下一步：权限”。 这些作用域将被添加到应用注册中，但你也可以稍后更改它们。 如果选择了外部配置，则可以稍后添加 Microsoft Graph 权限。

选择 添加 。

现在，你可以在应用中使用 Microsoft 标识平台进行身份验证了。 该提供程序将在“身份验证”屏幕上列出。 在该屏幕上，你可以编辑或删除此提供程序配置。

授权请求

默认情况下，应用服务身份验证仅处理身份验证，确定调用方是否符合他们声称的身份。 授权（确定调用方是否应有权访问某些资源）是身份验证之外的额外步骤。 可以从 Microsoft 标识平台授权基础知识中了解有关这些概念的详细信息。

你的应用可以在代码中做出授权决策。 应用服务身份验证确实提供了一些内置检查，这些检查可能有所帮助，但它们可能不足以满足应用的授权需求。

从应用程序代码执行验证

在应用代码中执行授权检查时，可以使用应用服务身份验证提供的声明信息。 注入的 x-ms-client-principal 标头包含 Base64 编码的 JSON 对象，其中包含有关调用方的断言的声明。 默认情况下，这些声明会经过声明映射，因此声明名称可能并不总是与令牌中显示的名称匹配。 例如，tid 声明会转而映射到 http://schemas.microsoft.com/identity/claims/tenantid。

还可以直接使用注入的 x-ms-token-aad-access-token 标头中的基础访问令牌。

使用内置授权策略

创建的应用注册会对你的 Microsoft Entra 租户的传入请求进行身份验证。 默认情况下，它让租户中的任何人都可以访问应用程序，这对许多应用程序来说没有问题。 但是，某些应用程序需要通过授权决策来进一步限制访问。 应用程序代码通常是处理自定义授权逻辑的最佳位置。 但是，对于常见方案，Microsoft 标识平台提供了内置检查，可用于限制访问。

本部分介绍如何使用应用服务身份验证 V2 API 启用内置检查。 目前，配置这些内置检查的唯一方法是通过 Azure 资源管理器模板或 REST API。

在 API 对象中，Microsoft Entra 标识提供者配置具有一个 validation 部分，该部分可包含一个 defaultAuthorizationPolicy 对象，如以下结构所示：

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}

properties	说明
defaultAuthorizationPolicy	访问应用必须满足的一组要求。 访问权限基于对其每个已配置属性的逻辑 AND 授予。 同时配置 allowedApplications 和 allowedPrincipals 时，传入请求必须同时满足这两个要求才能被接受。
allowedApplications	字符串应用程序客户端 ID 的允许列表，这些 ID 表示正在调用到应用的客户端资源。 当此属性配置为非空数组时，只有通过列表中指定应用程序获得的令牌才会被接受。 此策略评估传入令牌的 appid 或 azp 声明，该令牌必须是访问令牌。 请参阅 Microsoft 标识平台声明参考。
allowedPrincipals	用于确定传入请求表示的主体是否可以访问应用的一组检查。 allowedPrincipals 的达成度基于对其已配置的属性的逻辑 OR。
identities（在 allowedPrincipals 下）	表示具有访问权限的用户或应用程序的字符串对象 ID 的允许列表。 当此属性配置为非空数组时，如果列表中指定了由请求表示的用户或应用程序，则可以满足 allowedPrincipals 要求。 标识列表有 500 个总字符的限制。 此策略评估传入令牌的 oid 声明。 请参阅 Microsoft 标识平台声明参考。

此外，无论使用的 API 版本如何，都可以通过应用程序设置配置某些检查。 WEBSITE_AUTH_AAD_ALLOWED_TENANTS 应用程序设置可配置最多 10 个租户 ID 的逗号分隔列表（例如“aaaabbbb-0000-cccc-1111-dddd2222eeee”），从而要求传入令牌来自 tid 声明指定的租户之一。 可以将 WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL 应用程序设置配置为“true”或“1”，以要求传入令牌包含 oid 声明。 如果 allowedPrincipals.identities 已配置，则此设置会被忽略并视为 true，因为已根据此提供的标识列表检查了 oid 声明。

这些内置检查失败的请求会得到 HTTP 403 Forbidden 响应。

配置客户端应用以访问应用服务

在上一部分中，你注册了应用服务或 Azure Function 以便对用户进行身份验证。 本部分介绍如何在 Microsoft Entra 中注册本机客户端或守护程序应用，让它们能够代表用户或自行请求访问你的应用服务公开的 API，例如在 N 层体系结构中。 如果你只想要对用户进行身份验证，则不需要完成本部分所述的步骤。

本机客户端应用程序

可以注册本机客户端，以代表已登录用户请求访问应用服务应用的 API。

1. 在门户菜单中，选择“Microsoft Entra”。

2. 在左侧导航栏中，选择“应用注册”>“新建注册”。

3. 在“注册应用”页上的“名称”中，输入应用注册的名称。

4. 在“重定向 URI”中，选择“公共客户端(移动和桌面)”，然后键入 URL“<app-url>/.auth/login/aad/callback”。 例如 https://contoso.chinacloudsites.cn/.auth/login/aad/callback。

5. 选择“注册”。

6. 创建应用注册后，复制“应用程序(客户端) ID”的值。

   注意

   对于Microsoft Store 应用程序，请改用包 SID 作为 URI。

7. 在左侧导航栏中，选择“API 权限”>“添加权限”>“我的 API”。

8. 选择前面为应用服务应用创建的应用注册。 如果没有看到应用注册，请确保已在应用注册中添加 user_impersonation 范围。

9. 在“委托的权限”下，依次选择“user_impersonation”和“添加权限”。

现已配置一个可以代表用户请求访问应用服务应用的本机客户端应用程序。

守护程序客户端应用程序（服务到服务的调用）

在 n 层体系结构中，客户端应用程序可以获取令牌来代表客户端应用（并非代表用户）调用应用服务或函数应用。 此方案适用于在没有登录用户的情况下执行任务的非交互式后台程序应用程序。 它使用标准 OAuth 2.0 客户端凭据授权。

1. 在门户菜单中，选择“Microsoft Entra”。
2. 在左侧导航栏中，选择“应用注册”>“新建注册”。
3. 在“注册应用”页上的“名称”中，输入应用注册的名称。
4. 对于后台应用程序，不需要“重定向 URI”，因此可将其保留为空。
5. 选择“注册”。
6. 创建应用注册后，复制“应用程序(客户端) ID”的值。
7. 从左侧导航中，选择“证书和机密”>“客户端密码”>“新建客户端密码”。
8. 输入说明和过期时间，然后选择“添加”。
9. 在“值”字段中，复制客户端密码值。 离开此页面后，它将不会再次显示。

现在可以通过将 resource 参数设置为目标应用的“应用程序 ID URI”，使用客户端 ID 和客户端机密请求访问令牌。 然后，可以使用标准 OAuth 2.0 授权标头将生成的访问令牌提供给目标应用，应用服务身份验证将像平常一样验证和使用该令牌，以指示调用方（在本例中是应用程序，不是用户）已进行身份验证。

目前，这允许 Microsoft Entra 租户中的任何客户端应用程序请求访问令牌，并向目标应用进行身份验证。 如果还想要强制授权以只允许某些客户端应用程序，则必须执行一些额外配置。

1. 在表示要保护的应用服务或 Functions 应用的应用注册清单中定义应用角色。
2. 在表示需要获得授权的客户端的应用注册上，选择“API 权限”>“添加权限”>“我的 API”。
3. 选择之前创建的应用注册。 如果看不到应用注册，请确保已添加应用角色。
4. 在“应用程序权限”下，选择之前创建的应用角色，然后选择“添加权限”。
5. 确保选择“授予管理员同意”以授权客户端应用程序请求权限。
6. 与前面的方案（添加任何角色之前）类似，现在可以为同一目标 resource请求访问令牌，而访问令牌将包括一个 roles 声明，其中包含授权给客户端应用程序的应用角色。
7. 在目标应用服务或 Functions 应用代码中，现在可以验证令牌中是否存在预期的角色（这不是由应用服务身份验证执行的）。 有关详细信息，请参阅访问用户声明。

现已配置可以使用自己的标识访问应用服务应用的后台程序客户端应用程序。

最佳做法

无论使用哪种配置来设置身份验证，以下最佳做法都能使租户和应用程序保持更高的安全性：

• 在 Microsoft Entra 中为每个应用服务应用配置各自的应用注册。
• 为每个应用服务应用提供其自身的权限和许可。
• 避免通过对不同的部署槽使用不同的应用注册，在环境之间共享权限。 在测试新代码时，这种做法可有助于防止出现影响生产应用的问题。

后续步骤

• 应用服务身份验证/授权概述。
• Azure 应用服务中的身份验证和授权的高级用法

• 教程：在访问 Azure 存储和 Azure Graph 的 Web 应用中对用户进行身份验证和授权