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

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

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

Note

无需使用应用服务进行身份验证和授权。 许多 Web 框架绑定了安全功能,你可以根据需要使用不同的功能。 如果所需的灵活性超出了应用服务能够提供的范畴,还可以编写自己的实用工具。

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

工作原理

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

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

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

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

用户声明

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

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

令牌存储

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

  • 从 Azure Active Directory 图形 API 甚至 Microsoft Graph 中读取用户的企业数据

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

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

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

日志记录和跟踪

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

标识提供者

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

提供程序 登录终结点
Azure Active Directory /.auth/login/aad
Microsoft 帐户 /.auth/login/microsoft

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

身份验证流

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

  • 不使用提供程序 SDK:应用程序向应用服务委托联合登录。 浏览器应用通常采用此方案,这可以防止向用户显示提供程序的登录页。 服务器代码管理登录过程,因此,此流也称为“服务器导向流”或“服务器流”。 此方案适用于 Web 应用。 它也适用于使用移动应用客户端 SDK 登录用户的本机应用,因为 SDK 会打开 Web 视图,使用应用服务身份验证将用户登录。
  • 使用提供程序 SDK:应用程序手动将用户登录,然后将身份验证令牌提交给应用服务进行验证。 无浏览器应用通常采用此方案,这可以防止向用户显示提供程序的登录页。 应用程序代码管理登录过程,因此,此流也称为“客户端导向流”或“客户端流”。 此方案适用于 REST API 和 JavaScript 浏览器客户端,以及在登录过程中需要更高灵活性的 Web 应用。 它还适用于使用提供程序 SDK 登录用户的本机移动应用。 下表说明了身份验证流的步骤。
步骤 不使用提供程序 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 门户中,可以使用多种行为配置应用服务授权。

以下标题介绍了选项。

允许所有请求(默认设置)

身份验证和授权不由应用服务管理(禁用)。

如果不需要身份验证和授权,或者想要编写自己的身份验证和授权代码,请选择此选项。

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

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

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

允许所有请求,但验证已经过身份验证的请求

选项为“允许匿名请求”。 此选项将在应用服务中启用身份验证和授权,但会推迟对应用程序代码所做的授权决策。 对于经过身份验证的请求,应用服务还会在 HTTP 标头中一起传递身份验证信息。

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

更多资源

教程:在 Azure 应用服务中对用户进行端到端身份验证和授权
在应用服务中自定义身份验证和授权

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