您现在访问的是微软AZURE全球版技术文档网站，若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站，请访问 https://docs.azure.cn.

Azure 应用服务中的身份验证和授权Authentication and authorization in Azure App Service

本文内容

备注

目前，不支持 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 应用服务对移动应用进行用户身份验证和授权。

工作原理How it works

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

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

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

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

用户声明User claims

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

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

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

令牌存储Token store

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

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

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

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

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

日志记录和跟踪Logging and tracing

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

标识提供者Identity providers

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

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

身份验证流Authentication flow

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

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

备注

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

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

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

授权行为Authorization behavior

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

以下标题介绍了选项。

允许匿名请求（无操作）Allow Anonymous requests (no action)

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

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

仅允许经过身份验证的请求Allow only authenticated requests

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

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

注意

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

更多资源More resources

教程：在 Azure 应用服务 (Windows) 中对用户进行端到端身份验证和授权教程：在适用于 Linux 的 Azure 应用服务中对用户进行端到端身份验证和授权在应用服务中自定义身份验证和授权

特定于提供程序的操作方法指南：

• 如何将应用配置为使用 Azure Active Directory 登录
• 如何将应用配置为使用 Facebook 登录
• 如何将应用配置为使用 Google 登录
• 如何将应用配置为使用 Microsoft 帐户登录
• 如何将应用配置为使用 Twitter 登录
• 如何对应用程序使用自定义身份验证