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

备注

目前，不支持 AAD V2 （包括 MSAL） Azure 应用服务和 Azure Functions。请查看是否有更新。

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

安全身份验证和授权需要对联合身份验证、加密、JSON Web 令牌 (JWT) 管理、授权类型等安全性方面有深度的了解。应用服务提供这些实用工具，让你将更多的时间和精力花费在为客户提供业务价值上。

重要

对于身份验证/AuthO，无需使用应用服务。可以在所选的 web 框架中使用捆绑的安全功能，也可以编写自己的实用程序。但请记住， Chrome 80 对 cookie 的 SameSite 实现（年 3 2020 月的发布日期）进行重大更改，并且自定义远程身份验证或依赖于跨站点 cookie 发布的其他方案可能会在客户端 Chrome 浏览器更新时中断。解决方法非常复杂，因为它需要为不同的浏览器支持不同的 SameSite 行为。

应用服务托管的 ASP.NET Core 2.1 及更高版本已针对此重大更改进行了修补，并相应地处理 Chrome 80 和更低版本的浏览器。此外，ASP.NET Framework 4.7.2 的相同修补程序在2020年1月的应用服务实例上部署。有关详细信息，包括如何了解应用是否已收到修补程序，请参阅Azure App Service SameSite cookie 更新。

有关特定于本机移动应用的信息，请参阅使用 Azure 应用服务对移动应用进行用户身份验证和授权。

工作原理

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

此模块为应用处理多项操作：

使用指定的提供程序对用户进行身份验证
验证、存储和刷新令牌
管理经过身份验证的会话
将标识信息插入请求标头

此模块独立于应用程序代码运行，使用应用设置进行配置。不需要任何 SDK、特定语言，或者对应用程序代码进行更改。

用户声明

对于所有语言框架，应用服务通过将用户声明注入请求标头，向代码提供这些声明。对于 ASP.NET 4.6 应用，应用服务会在 ClaimsPrincipal.Current 中填充经过身份验证的用户声明，使你能够遵循标准的 .NET 代码模式（包括 [Authorize] 属性）。同样，对于 PHP 应用，应用服务会填充 _SERVER['REMOTE_USER'] 变量。对于 Java 应用，可从 Tomcat servlet 访问声明。

对于 Azure Functions，.NET 代码的 ClaimsPrincipal.Current 不会解冻，但仍可以在请求标头中找到用户声明。

有关详细信息，请参阅访问用户声明。

令牌存储

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

发布到经过身份验证的用户的 Facebook 时间线
从 Azure Active Directory 图形 API 甚至 Microsoft Graph 中读取用户的企业数据

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

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

如果不需要在应用中使用令牌，可以禁用令牌存储。

日志记录和跟踪

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

标识提供者

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

提供商	登录终结点
Azure Active Directory	`/.auth/login/aad`
Microsoft 帐户	`/.auth/login/microsoftaccount`
Facebook	`/.auth/login/facebook`
Google	`/.auth/login/google`
Twitter	`/.auth/login/twitter`

对其中一个提供程序启用身份验证和授权时，其登录终结点可用于用户身份验证，以及验证来自提供程序的身份验证令牌。可以轻松为用户提供其中任意数量的登录选项。你还可以集成其他标识提供程序或你自己的自定义标识解决方案。

身份验证流

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

不使用提供程序 SDK：应用程序向应用服务委托联合登录。浏览器应用通常采用此方案，这可以防止向用户显示提供程序的登录页。服务器代码管理登录过程，因此，此流也称为“服务器导向流”或“服务器流”。此方案适用于浏览器应用。它也适用于使用移动应用客户端 SDK 登录用户的本机应用，因为 SDK 会打开 Web 视图，使用应用服务身份验证将用户登录。
使用提供程序 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` 标头中提供身份验证令牌（由移动应用客户端 SDK 自动处理）。

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

授权行为

在Azure 门户中，当传入请求未经过身份验证时，你可以使用多种行为配置应用服务授权。

以下标题介绍了选项。

允许匿名请求（无操作）

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

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

仅允许经过身份验证的请求

选项为“使用 提供程序> 登录”。< 应用服务将所有匿名请求重定向到所选提供程序的 /.auth/login/<provider>。如果匿名请求来自本机移动应用，则返回的响应为 HTTP 401 Unauthorized。

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

注意

以这种方式限制访问权限适用于对应用的所有调用，对于需要公开提供的主页的应用，与在许多单页应用程序中一样。

Azure身份验证