Azure 应用服务和 Azure Functions 中的身份验证和授权,azure创建博客-ESG跨境

Azure 应用服务和 Azure Functions 中的身份验证和授权,azure创建博客

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

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

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

重要

你并非必须使用此功能进行身份验证和授权。可以在所选的Web框架中使用捆绑的安全功能，也可以编写自己的实用程序。但请记住，Chrome 80针对Cookie对其实现SameSite的方式进行了中断性变更（发布日期在2020年3月左右）；自定义远程身份验证或依赖于跨站点Cookie发布的其他方案可能会在客户端Chrome浏览器更新时中断。解决方法很复杂，因为需要针对不同的浏览器支持不同的SameSite行为。

应用服务托管的ASP.NET Core 2.1及更高版本已针对此中断性变更进行了修补，并且会相应地处理Chrome 80和更低版本的浏览器。此外，我们还在整个2020年1月在应用服务实例上部署了ASP.NET Framework 4.7.2的同一修补程序。有关详细信息，请参阅Azure应用服务SameSite Cookie更新。

备注

“身份验证/授权”功能有时也称为“简单身份验证/授权”。

备注

启用此功能会导致对应用程序的所有非安全HTTP请求自动重定向到HTTPS，而不管强制实施HTTPS所需的应用服务配置设置如何。如果需要，可以通过身份验证/授权设置配置文件中的requireHttps设置禁用此功能，但需注意确保不通过非安全HTTP连接传输安全令牌。

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

工作原理

在Windows上

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

一个体系结构图，显示请求被站点沙盒中的进程拦截，该进程与标识提供者进行交互，然后再允许流量发往已部署的站点

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

·使用指定的提供程序对用户进行身份验证

·验证、存储和刷新令牌

·管理经过身份验证的会话

·将标识信息插入请求标头

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

用户/应用程序声明

对于所有语言框架，应用服务都通过将传入令牌（无论是来自经过身份验证的最终用户还是来自客户端应用程序）中的声明注入请求标头，使其可供代码使用。对于ASP.NET 4.6应用，应用服务会在ClaimsPrincipal.Current中填充经过身份验证的用户声明，使你能够遵循标准的.NET代码模式（包括[Authorize]属性）。同样，对于PHP应用，应用服务会填充SERVER[REMOTEUSER]变量。对于Java应用，可从Tomcat servlet访问声明。

对于Azure Functions，没有为.NET代码填充ClaimsPrincipal.Current，但你仍然可以在请求标头中找到用户声明，也可通过请求上下文甚至通过绑定参数来获取ClaimsPrincipal对象。有关详细信息，请参阅使用客户端标识。

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

备注

目前，ASP.NET Core不支持为当前用户填充身份验证/授权功能。但是，确实存在一些第三方开源中间件组件，可以帮助填补这一空白。

令牌存储

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

发布到经过身份验证用户的MicrosoftAccount时间线

使用Microsoft Graph API读取用户的公司数据

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

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

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

日志记录和跟踪

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

标识提供者

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

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

存在旧版可扩展性路径，用于与其他标识提供者或自定义身份验证/授权解决方案集成，但是不建议使用，而应考虑使用OpenID Connect支持。

身份验证流

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

·不使用提供程序SDK：应用程序向应用服务委托联合登录。浏览器应用通常采用此方案，这可以防止向用户显示提供程序的登录页。服务器代码管理登录过程，因此，此流也称为“服务器导向流”或“服务器流”。此方案适用于浏览器应用。它也适用于使用移动应用客户端SDK登录用户的本机应用，因为SDK会打开Web视图，使用应用服务身份验证将用户登录。

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

备注

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

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

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

授权行为

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

一个屏幕截图，显示“请求未通过身份验证时要采取的操作”下拉列表

以下标题介绍了选项。

允许匿名请求(无操作)

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

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

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

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

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

注意

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

备注

默认情况下，Azure AD租户中的任何用户都可以从Azure AD请求应用程序的令牌。若要仅允许一组定义的用户访问应用，可以在Azure AD中配置应用程序。

特别声明：以上文章内容仅代表作者本人观点，不代表ESG跨境电商观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与ESG跨境电商联系。