Azure 应用服务和 Azure Functions 中的身份验证和授权
注意
从 2024 年 6 月 1 日开始，所有新创建的应用服务应用都可以选择生成唯一的默认主机名，命名约定为 <app-name>-<random-hash>.<region>.chinacloudsites.cn。 现有应用名称将保持不变。
示例： myapp-ds27dh7271aah175.westus-01.chinacloudsites.cn
Azure 应用服务提供内置的身份验证和授权功能（有时称为“简易身份验证”）。只需在 Web 应用、RESTful API、移动后端和 Azure Functions 中编写少量的代码或根本无需编写代码，就能让用户登录和访问数据。 本文介绍应用服务如何帮助简化应用的身份验证和授权。
为何使用内置身份验证？
你并非必须使用此功能进行身份验证和授权。 可以在所选的 Web 框架中使用捆绑的安全功能，也可以编写自己的实用程序。 但你需要确保您的解决方案与最新的安全性、协议和浏览器更新保持同步。
实现安全的身份验证（登录用户）和授权（提供对安全数据的访问）解决方案需要耗费大量精力。 必须确保遵循行业最佳做法和标准，并使实现保持最新。 适用于应用服务和 Azure Functions 的内置身份验证功能通过联合标识提供者提供现成的身份验证，可为你节省时间和精力，使你能够专注于应用程序的其余部分。
- 借助 Azure 应用服务，可以将各种身份验证功能集成到 Web 应用或 API 中，而无需你自行实现。
- 它直接内置于平台中，无需使用任何特定的语言、SDK、安全专业知识甚至任何代码。
- 可与多个登录提供商集成。 例如 Microsoft Entra。
你的应用可能需要支持更复杂的方案，例如 Visual Studio 集成或增量许可。 有多种不同的身份验证解决方案可用于支持这些方案。 若要了解详细信息，请阅读标识方案。
标识提供者
默认提供以下标识提供者：
| 提供程序 | 登录终结点 | 操作说明指南 |
|---|---|---|
| Microsoft 标识平台 | /.auth/login/aad |
应用服务 Microsoft 标识平台登录 |
| 任何 OpenID Connect 提供程序 | /.auth/login/<providerName> |
应用服务 OpenID Connect 登录 |
对其中一个提供程序配置此功能时，其登录终结点可用于用户身份验证，以及验证来自提供程序的身份验证令牌。 你可以轻松为用户提供任意数量的登录选项。
使用内置身份验证的注意事项
启用此功能会导致向应用程序发出的所有请求自动重定向到 HTTPS，而不管用于实施 HTTPS 的应用服务配置设置如何。 可以通过 V2 配置中的 requireHttps 设置来禁用此功能。 但建议一直使用 HTTPS，且应确保不会通过不安全的 HTTP 连接传输安全令牌。
应用服务可用于在限制或不限制对站点内容和 API 的访问的情况下进行身份验证。 可以在 Web 应用的“身份验证”>“身份验证设置”部分中设置访问限制。 若要仅限经过身份验证的用户访问应用，请将“请求未经过身份验证时需执行的操作”设置为使用已配置的标识提供程序之一登录�。 若要进行身份验证但不限制访问权限，请将“请求未经过身份验证时需执行的操作”设置为“允许匿名请求(无操作)”。
重要
应为每个应用注册指定它自己的权限和同意。 避免通过对不同的部署槽使用不同的应用注册，在环境之间共享权限。 测试新代码时，这种做法有助于防止问题影响到生产应用。
工作原理
功能体系结构
身份验证和授权中间件组件是平台的一项功能，该功能与应用程序在同一 VM 上运行。 启用后，每个传入的 HTTP 请求都将通过此组件，然后由应用程序处理。
此平台中间件为应用处理多项操作：
- 使用指定的标识提供者对用户和客户端进行身份验证
- 验证、存储和刷新由已配置的标识提供程序颁发的 OAuth 令牌
- 管理经过身份验证的会话
- 将标识信息插入到 HTTP 请求头
模块独立于应用程序代码运行，可使用 Azure 资源管理器设置进行配置。 不需要任何 SDK、特定编程语言，也无需对应用程序代码进行更改。
身份验证流
身份验证流对于所有提供程序是相同的，但根据是否要使用提供程序的 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 授权基础知识。
日志记录和跟踪
如果启用应用程序日志记录，将在日志文件中直接看到身份验证和授权跟踪。 如果出现意外的身份验证错误，查看现有的应用程序日志即可方便找到所有详细信息。 如果启用失败请求跟踪，可以确切地查看身份验证和授权模块在失败请求中发挥的作用。 在跟踪日志中，找到对名为 EasyAuthModule_32/64 的模块的引用。
更多资源
示例：