你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

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

项目
11/05/2024

注意

从 2024 年 6 月 1 日开始，所有新创建的应用服务应用都可以选择生成唯一的默认主机名，命名约定为 <app-name>-<random-hash>.<region>.azurewebsites.net。现有应用名称将保持不变。

示例： myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Azure 应用服务提供内置的身份验证和授权功能（有时称为“简易身份验证”）。只需在 Web 应用、RESTful API、移动后端和 Azure Functions 中编写少量的代码或根本无需编写代码，就能让用户登录和访问数据。本文介绍应用服务如何帮助简化应用的身份验证和授权。

为何使用内置身份验证？

你并非必须使用此功能进行身份验证和授权。可以在所选的 Web 框架中使用捆绑的安全功能，也可以编写自己的实用程序。但你需要确保您的解决方案与最新的安全性、协议和浏览器更新保持同步。

实现安全的身份验证（登录用户）和授权（提供对安全数据的访问）解决方案需要耗费大量精力。必须确保遵循行业最佳做法和标准，并使实现保持最新。适用于应用服务和 Azure Functions 的内置身份验证功能通过联合标识提供者提供现成的身份验证，可为你节省时间和精力，使你能够专注于应用程序的其余部分。

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

你的应用可能需要支持更复杂的方案，例如 Visual Studio 集成或增量许可。有多种不同的身份验证解决方案可用于支持这些方案。若要了解详细信息，请阅读标识方案。

标识提供者

应用服务使用联合标识，其中第三方标识提供者为你管理用户标识和身份验证流。默认提供以下五个标识提供者：

提供程序	登录终结点	操作说明指南
Microsoft Entra	`/.auth/login/aad`	应用服务 Microsoft Entra 平台登录
Facebook	`/.auth/login/facebook`	应用服务 Facebook 登录
Google	`/.auth/login/google`	应用服务 Google 登录
X	`/.auth/login/x`	应用服务 X 登录
GitHub	`/.auth/login/github`	应用服务 GitHub 登录
使用 Apple 登录	`/.auth/login/apple`	应用服务 Apple 登录（预览版）
任何 OpenID Connect 提供程序	`/.auth/login/<providerName>`	应用服务 OpenID Connect 登录

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

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

启用此功能会导致向应用程序发出的所有请求自动重定向到 HTTPS，而不管用于实施 HTTPS 的应用服务配置设置如何。可以通过 V2 配置中的 requireHttps 设置来禁用此功能。但建议一直使用 HTTPS，且应确保不会通过不安全的 HTTP 连接传输安全令牌。

应用服务可用于在限制或不限制对站点内容和 API 的访问的情况下进行身份验证。可以在 Web 应用的“身份验证”>“身份验证设置”部分中设置访问限制。若要仅限经过身份验证的用户访问应用，请将“请求未经过身份验证时需执行的操作”设置为使用某个配置的标识提供者登录。若要进行身份验证但不限制访问权限，请将“请求未经过身份验证时需执行的操作”设置为“允许匿名请求(无操作)”。

重要

应为每个应用注册指定它自己的权限和同意。避免通过对不同的部署槽使用不同的应用注册，在环境之间共享权限。测试新代码时，这种做法有助于防止问题影响到生产应用。

工作原理

功能体系结构

身份验证和授权中间件组件是平台的一项功能，该功能与应用程序在同一 VM 上运行。启用后，每个传入的 HTTP 请求都将通过此组件，然后由应用程序处理。

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

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

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

Windows 上的功能体系结构（非容器部署）

身份验证和授权模块在应用程序所在的同一沙盒中作为本机 IIS 模块运行。启用后，每个传入的 HTTP 请求将通过此模块，然后由应用程序处理。

Linux 和容器上的功能体系结构

身份验证和授权模块在独立于应用程序代码的单独容器中运行。使用所谓的代表模式，它与传入的流量交互，以执行与在 Windows 上所执行的类似功能。由于它不在进程内运行，因此不能与特定的语言框架直接集成；但是，应用所需的相关信息通过使用请求标头进行传递，如下所述。

身份验证流

身份验证流对于所有提供程序是相同的，但根据是否要使用提供程序的 SDK 登录而有所差别：

不使用提供程序 SDK：应用程序向应用服务委托联合登录。浏览器应用通常采用此方案，这可以防止向用户显示提供程序的登录页。服务器代码管理登录过程，因此，此流也称为“服务器导向流”或“服务器流”。这种情况适用于使用嵌入式浏览器进行身份验证的浏览器应用和移动应用。
使用提供程序 SDK：应用程序手动将用户登录到提供程序，然后将身份验证令牌提交给应用服务进行验证。无浏览器应用通常采用此方案，这可以防止向用户显示提供程序的登录页。应用程序代码管理登录过程，因此，此流也称为“客户端导向流”或“客户端流”。此方案适用于 REST API、Azure Functions 和 JavaScript 浏览器客户端，以及在登录过程中需要更高灵活性的浏览器应用。它还适用于使用提供程序 SDK 登录用户的本机移动应用。

对于应用服务中受信任浏览器应用对应用服务或 Azure Functions 中另一 REST API 的调用，可以使用服务器导向流对其进行身份验证。有关详细信息，请参阅自定义登录和注销。

下表说明了身份验证流的步骤。

步骤	不使用提供程序 SDK	使用提供程序 SDK
1.将用户登录	将客户端重定向到 `/.auth/login/<provider>`。	客户端代码直接使用提供程序的 SDK 将用户登录，并接收身份验证令牌。有关详细信息，请参阅提供程序文档。
2.身份验证后	提供程序将客户端重定向到 `/.auth/login/<provider>/callback`。	客户端代码将来自提供程序的令牌发布到`/.auth/login/<provider>` 进行验证。
3.建立经过身份验证的会话	应用服务将经过身份验证的 Cookie 添加到响应中。	应用服务将自身的身份验证令牌返回给客户端代码。
4.提供经过身份验证的内容	客户端在后续请求中包含身份验证 Cookie（由浏览器自动处理）。	客户端代码在 `X-ZUMO-AUTH` 标头中提供身份验证令牌。

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

授权行为

重要

默认情况下，此功能仅提供身份验证，不提供授权。除了在此处配置的任何检查外，应用程序可能还需要做出授权决策。

在 Azure 门户中，当传入请求未经过身份验证时，可以使用多种行为配置应用服务。以下标题介绍了选项。

限制访问

允许未经授权的请求 此选项将对未经身份验证的流量的授权交给应用程序代码处理。对于经过身份验证的请求，应用服务还会在 HTTP 标头中一起传递身份验证信息。

使用此选项可以更灵活地处理匿名请求。例如，可以向用户提供多个登录提供程序。但是，必须编写代码。
需要身份验证 此选项将拒绝任何未经身份验证的应用程序流量。 “未经身份验证的请求”部分指定了要采取的具体操作。

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

注意

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

注意

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

未经身份验证的请求

HTTP 302 找到重定向：建议用于网站 将操作重定向到所配置的标识提供者之一。在这些情况下，浏览器客户端将重定向到所选提供商的 /.auth/login/<provider>。
HTTP 401 未经授权：建议用于 API 如果匿名请求来自原生移动应用，则返回的响应为 HTTP 401 Unauthorized。你还可针对所有请求将拒绝配置为 HTTP 401 Unauthorized。
HTTP 403 被禁止 针对所有请求将拒绝配置为 HTTP 403 Forbidden。
HTTP 404 未找到 针对所有请求将拒绝配置为 HTTP 404 Not found。

令牌存储

应用服务提供内置的令牌存储，这是与 Web 应用、API 或本机移动应用的用户相关联的令牌存储库。对任何提供程序启用身份验证时，此令牌存储可立即供应用使用。如果应用程序代码需要代表用户访问这些提供程序中的数据，例如：

发布到经过身份验证的用户的 Facebook 时间线
使用 Microsoft Graph API 读取用户的公司数据

通常，必须编写代码才能在应用程序中收集、存储和刷新这些令牌。使用令牌存储，只需在需要令牌时才检索令牌；当令牌失效时，可以告知应用服务刷新令牌。

ID 令牌、访问令牌和刷新令牌会为经过身份验证的会话进行缓存，且只能由关联的用户访问。

如果不需要在应用中使用令牌，可以在应用的“身份验证/授权”页中禁用令牌存储。

日志记录和跟踪

如果启用应用程序日志记录，将在日志文件中直接看到身份验证和授权跟踪。如果出现意外的身份验证错误，查看现有的应用程序日志即可方便找到所有详细信息。如果启用失败请求跟踪，可以确切地查看身份验证和授权模块在失败请求中发挥的作用。在跟踪日志中，找到对名为 EasyAuthModule_32/64 的模块的引用。

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

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

这是一个使用会话 Cookie 进行身份验证的 POST 请求。
请求来自已知浏览器（由 HTTP User-Agent 标头确定）。
HTTP Origin 或 HTTP Referer 标头缺失，或者不在配置的已批准重定向外部域列表中。
HTTP Origin 标头缺失，或不在配置的 CORS 来源列表中。

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

使用 Azure Front Door 时的注意事项

在 Azure Front Door 或其他反向代理后面使用采取身份验证的 Azure 应用服务时，需要考虑一些其他事项。

为身份验证工作流禁用 Front Door 缓存。
使用 Front Door 终结点进行重定向。

通过 Azure Front Door 公开时，应用服务通常无法直接访问。例如，可以通过 Azure Front Door Premium 中的专用链接公开应用服务来防止这种情况发生。为防止身份验证工作流将流量直接重定向回应用服务，必须将应用程序配置为重定向回 https://<front-door-endpoint>/.auth/login/<provider>/callback。
确保应用服务使用正确的重定向 URI

在某些配置中，应用服务使用应用服务 FQDN 作为重定向 URI，而不是 Front Door FQDN。当客户端被重定向到应用服务而不是 Front Door 时，这将导致问题。若要更改此设置，需要将 forwardProxy 设置设置为 Standard，以使应用服务遵循 Azure Front Door 设置的 X-Forwarded-Host 标头。

Azure 应用程序网关或第 3 方产品等其他反向代理可能使用不同的标头并需要不同的 forwardProxy 设置。

此配置目前无法通过 Azure 门户完成，需要通过 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 应用服务和 Azure Functions 中的身份验证和授权

为何使用内置身份验证？

标识提供者

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

工作原理

功能体系结构

Windows 上的功能体系结构（非容器部署）

Linux 和容器上的功能体系结构

身份验证流

授权行为

令牌存储

日志记录和跟踪

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

使用 Azure Front Door 时的注意事项

更多资源

反馈

其他资源