Azure 应用服务和 Azure Functions 中的身份验证和授权

Azure 应用服务提供内置身份验证（登录用户）和授权（提供对安全数据的访问权限）功能。 这些功能有时称为 Easy Auth。可以通过在 Web 应用、RESTful API、移动服务器和 函数中编写很少或无代码来让用户登录和访问数据。

本文介绍应用服务如何帮助简化应用的身份验证和授权。

使用内置身份验证的原因

要实现身份验证和授权，可以使用所选 Web 框架中的捆绑安全功能，也可以编写自己的工具。 实现用于身份验证和授权的安全解决方案可能会花费大量精力。 你需要遵循行业最佳做法和标准。 你还需要通过最新的安全、协议和浏览器更新来确保解决方案始终是最新状态。

应用服务和 Azure Functions 的内置功能可以通过向联合身份验证标识提供程序提供现成身份验证来节省时间和精力，以便专注于应用程序的其余部分。

使用应用服务，可以将身份验证功能集成到 Web 应用或 API 中，而无需自行实现这些功能。 此功能直接内置于平台中，不需要任何特定的语言、SDK、安全专业知识或代码。 可以将它与多个登录提供程序集成，例如 Microsoft Entra、Facebook、Google 和 X。

应用可能需要支持更复杂的应用场景，例如 Visual Studio 集成或增量同意。 可以使用多种身份验证解决方案来支持这些应用场景。 若要了解详细信息，请参阅 身份验证方案和建议。

标识提供者

默认提供以下标识提供者：

对其中一个提供程序配置此功能时，其登录终结点可用于用户身份验证，以及验证来自提供程序的身份验证令牌。 你可以轻松为用户提供任意数量的登录选项。

使用内置身份验证的注意事项

启用内置身份验证会导致应用程序的所有请求都自动重定向到 HTTPS，而不管应用服务配置设置如何强制实施 HTTPS。 可以使用 V2 配置中的 requireHttps 设置禁用此自动重定向。 但是，我们建议继续使用 HTTPS，并确保从未通过不安全的 HTTP 连接传输任何安全令牌。

可以使用应用服务进行身份验证，无论是否限制对站点内容和 API 的访问。 在 Web 应用的 “设置>身份验证>身份验证设置” 部分设置访问限制：

• 要仅限经过身份验证的用户访问应用，请将“请求未经过身份验证时需执行的操作”设置为使用某个配置的标识提供程序登录。
• 要进行身份验证但不限制访问权限，请将“请求未经过身份验证时需执行的操作”设置为“允许匿名请求(无操作)”。

工作原理

功能体系结构

身份验证和授权中间件组件是平台的一项功能，与应用程序在同一虚拟机上运行。 启用它时，每个传入的 HTTP 请求都会在应用程序处理该组件之前通过该组件。

此平台中间件为应用处理多项操作：

• 使用指定的标识提供者对用户和客户端进行身份验证
• 验证、存储和刷新配置的标识提供者颁发的 OAuth 令牌
• 管理经过身份验证的会话
• 将标识信息插入到 HTTP 请求头

该模块独立于应用程序代码运行。 可以使用 Azure 资源管理器设置或使用配置文件对其进行配置。 不需要任何 SDK、特定编程语言，也无需对应用程序代码进行更改。

身份验证流

所有提供程序的身份验证流都是相同的。 这取决于您是否要使用提供程序的 SDK 进行登录：

• 不使用提供程序 SDK：应用程序向应用服务委托联合登录。 此过程通常发生在浏览器应用中，其可以向用户显示提供程序的登录页面。 服务器代码管理登录过程，因此它也称为“服务器导向流”或“服务器流”。

  这种情况适用于使用嵌入式浏览器进行身份验证的浏览器应用和移动应用。

• 使用提供程序 SDK：应用程序手动将用户登录到提供程序。 然后将身份验证令牌提交到应用服务进行验证。 此过程通常发生在无浏览器应用中，其无法向用户显示提供程序的登录页面。 应用程序代码管理登录过程，因此它也称为“客户端导向流”或“客户端流”。

  此情形适用于 REST API、Azure Functions 和 JavaScript 浏览器客户端，以及在登录过程中需要更高灵活性的浏览器应用。 它还适用于使用提供程序 SDK 登录用户的本机移动应用。

下表显示了身份验证流的步骤。

对于客户端浏览器，应用服务可自动将所有未经身份验证的用户定向到 /.auth/login/<provider>。 还可以向用户提供一个或多个 /.auth/login/<provider> 链接，让他们使用所选的提供程序登录到你的应用。

授权行为

在 Azure 门户中，可以在传入请求未进行身份验证时为应用服务配置各种行为。 以下部分将介绍这些选项。

受限访问

• 允许未经身份验证的请求：此选项会将对未经身份验证的流量授权推迟到由应用程序代码执行。 对于经过身份验证的请求，应用服务还会在 HTTP 标头中一起传递身份验证信息。

  使用此选项可以更灵活地处理匿名请求。 例如，它允许向用户提供多个登录提供程序。 但是，必须编写代码。

• 需要身份验证：此选项将拒绝任何未经身份验证的应用程序流量。 本文后面的未经身份验证的请求部分中指定了要采取的具体操作。

  使用此选项不需要在应用中编写任何身份验证代码。 可以通过检查用户的声明来处理较精细的授权，例如特定于角色的授权。

  注意

  以这种方式限制访问适用于对应用的所有调用，对于想要主页公开可用的应用程序来说，这可能是不可取的，就像在许多单页应用程序中一样。

  注意

  为组织中的用户使用 Microsoft 标识提供程序时，默认行为是 Microsoft Entra 租户中的任何用户都可以请求应用程序的令牌。 如果想要仅允许一组定义的用户访问应用，可以在 Microsoft Entra 中配置应用程序。 App 服务还提供了一些基本的内置授权检查，有助于进行一些验证。 若要详细了解 Microsoft Entra 中的授权，请参阅 Microsoft Entra 授权基础知识。

为组织中的用户使用 Microsoft 标识提供者时，默认行为是 Microsoft Entra 租户中的任何用户都可以请求应用程序的令牌。 如果想要仅允许一组定义的用户访问应用，可以在 Microsoft Entra 中配置应用程序。 应用服务还提供了一些基本的内置授权检查，有助于进行一些验证。 若要详细了解 Microsoft Entra 中的授权，请参阅 Microsoft Entra 授权基础知识。

日志记录和跟踪

如果启用应用程序日志记录，身份验证和授权跟踪将直接显示在日志文件中。 如果出现意外的身份验证错误，查看现有的应用程序日志即可方便找到所有详细信息。

如果启用 失败的请求跟踪，则可以确切地查看身份验证和授权模块在失败的请求中可能扮演的角色。 在跟踪日志中，找到对名为 EasyAuthModule_32/64 的模块的引用。

跨网站请求伪造攻击的缓解措施

应用服务身份验证通过检查客户端请求是否符合以下条件来缓解跨网站请求伪造：

• 它是通过会话 Cookie 进行身份验证的 POST 请求。
• 请求来自已知浏览器（由 HTTP User-Agent 标头确定）。
• HTTP Origin 或 HTTP Referer 标头缺失，或不在已配置的重定向外部域的批准列表中。
• HTTP Origin 标头缺失或不在配置的跨域资源共享 （CORS） 源列表中。

如果请求符合所有这些条件，应用服务身份验证会自动拒绝它。 可以通过在设置>身份验证>编辑身份验证设置>允许的外部重定向 URL中，将您的外部域添加到重定向列表中，来避开此缓解逻辑。

受保护的资源元数据（预览版）

应用服务可以提供 OAuth 2.0 保护的资源元数据，如 RFC 9728 中定义。 这有助于 OAuth 2.0 客户端了解如何与应用交互。 模型上下文协议（MCP）服务器授权是必备条件。

在预览期间，可以通过配置 WEBSITE_AUTH_PRM_DEFAULT_WITH_SCOPES应用程序设置 （包含应用程序所需的范围逗号分隔列表）来启用默认的受保护资源元数据文档。 例如，当你让应用服务为你配置 Microsoft Entra 提供程序时，它将设置一个权限范围，例如 api://<client-id>/user_impersonation，并用你的应用注册的实际客户端 ID 替换 <client-id>。

默认受保护的资源元数据文档包含以下属性：

使用默认配置时不支持其他属性。

配置默认保护的资源元数据文档也会更改应用服务如何处理未经身份验证的 API 请求。 当应用发出授权质询时，它包括受保护的资源元数据的 URL，然后客户端可以检索和处理这些元数据。 挑战还包括在应用程序设置中 WEBSITE_AUTH_PRM_DEFAULT_WITH_SCOPES 配置的作用域。

使用 Azure Front Door 的注意事项

在 Azure Front Door 或其他反向代理后面使用 Azure 应用服务进行身份验证时，请考虑执行以下操作。

禁用 Azure Front Door 缓存

为身份验证工作流禁用 Azure Front Door 缓存。

使用 Azure Front Door 终结点进行重定向

应用服务在 Azure Front Door 公开时通常无法直接访问。 例如，通过在 Azure Front Door Premium 中使用 Azure 专用链接公开应用服务，可以阻止此行为。 防止身份验证工作流将流量重定向回应用服务。 有关详细信息，请参阅 重定向 URI。

确保应用服务使用正确的重定向 URI

在某些配置中，应用服务使用其完全限定的域名 (FQDN) 作为重定向 URI，而不是 Azure Front Door FQDN。 当客户端重定向到应用服务而不是 Azure Front Door 时，此配置会导致问题。 要更改它，请将 forwardProxy 设置为 Standard 以使应用服务遵循 Azure Front Door 设置的 X-Forwarded-Host 标头。

其他反向代理（如 Azure 应用程序网关或非 Microsoft 产品）可能使用不同的标头，并且需要不同的 forwardProxy 设置。

无法使用 Azure 门户更改 forwardProxy 配置。 需要使用 az rest。

导出设置

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

更新设置

搜索：

"httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}

确保将 convention 设置为 Standard，以遵循 Azure Front Door 使用的 X-Forwarded-Host 标头。

导入设置

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

相关内容

有关应用服务身份验证的详细信息，请参阅：

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

• 在 Azure 应用服务身份验证中使用用户标识

相关示例如下所示：

• 快速入门：向 Azure 应用服务上运行的 Web 应用添加应用身份验证

• .NET Core 与 Azure AppService 简单身份验证的集成（非 Microsoft GitHub 内容）
• 使用 .NET Core 获取 Azure 应用服务身份验证（非 Microsoft GitHub 内容）