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

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

备注

目前, 不支持 AAD V2 (包括 MSAL) Azure 应用服务和 Azure Functions。At this time, AAD V2 (including MSAL) is not supported for Azure App Services and Azure Functions. 请查看是否有更新。Please check back for updates.

Azure 应用服务提供内置的身份验证和授权支持。只需在 Web 应用、RESTful API、移动后端和 Azure Functions 中编写少量的代码或根本无需编写代码,就能让用户登录和访问数据。Azure App Service provides built-in authentication and authorization support, so you can sign in users and access data by writing minimal or no code in your web app, RESTful API, and mobile back end, and also Azure Functions. 本文介绍应用服务如何帮助简化应用的身份验证和授权。This article describes how App Service helps simplify authentication and authorization for your app.

安全身份验证和授权需要对联合身份验证、加密、JSON Web 令牌 (JWT) 管理、授权类型等安全性方面有深度的了解。Secure authentication and authorization require deep understanding of security, including federation, encryption, JSON web tokens (JWT) management, grant types, and so on. 应用服务提供这些实用工具,让你将更多的时间和精力花费在为客户提供业务价值上。App Service provides these utilities so that you can spend more time and energy on providing business value to your customer.

备注

无需使用应用服务进行身份验证和授权。You're not required to use App Service for authentication and authorization. 许多 Web 框架绑定了安全功能,你可以根据需要使用不同的功能。Many web frameworks are bundled with security features, and you can use them if you like. 如果所需的灵活性超出了应用服务能够提供的范畴,还可以编写自己的实用工具。If you need more flexibility than App Service provides, you can also write your own utilities.

有关特定于本机移动应用的信息,请参阅使用 Azure 应用服务对移动应用进行用户身份验证和授权For information specific to native mobile apps, see User authentication and authorization for mobile apps with Azure App Service.

工作原理How it works

身份验证和授权模块在应用程序代码所在的同一沙盒中运行。The authentication and authorization module runs in the same sandbox as your application code. 启用后,每个传入的 HTTP 请求将通过此模块,然后由应用程序代码处理。When it's enabled, every incoming HTTP request passes through it before being handled by your application code.

此模块为应用处理多项操作:This module handles several things for your app:

  • 使用指定的提供程序对用户进行身份验证Authenticates users with the specified provider
  • 验证、存储和刷新令牌Validates, stores, and refreshes tokens
  • 管理经过身份验证的会话Manages the authenticated session
  • 将标识信息插入请求标头Injects identity information into request headers

此模块独立于应用程序代码运行,使用应用设置进行配置。The module runs separately from your application code and is configured using app settings. 不需要任何 SDK、特定语言,或者对应用程序代码进行更改。No SDKs, specific languages, or changes to your application code are required.

用户声明User claims

对于所有语言框架,应用服务通过将用户声明注入请求标头,向代码提供这些声明。For all language frameworks, App Service makes the user's claims available to your code by injecting them into the request headers. 对于 ASP.NET 4.6 应用,应用服务会在 ClaimsPrincipal.Current 中填充经过身份验证的用户声明,使你能够遵循标准的 .NET 代码模式(包括 [Authorize] 属性)。For ASP.NET 4.6 apps, App Service populates ClaimsPrincipal.Current with the authenticated user's claims, so you can follow the standard .NET code pattern, including the [Authorize] attribute. 同样,对于 PHP 应用,应用服务会填充 _SERVER['REMOTE_USER'] 变量。Similarly, for PHP apps, App Service populates the _SERVER['REMOTE_USER'] variable. 对于 Java 应用,可从 Tomcat servlet 访问声明。For Java apps, the claims are accessible from the Tomcat servlet.

对于 Azure Functions,.NET 代码的 ClaimsPrincipal.Current 不会解冻,但仍可以在请求标头中找到用户声明。For Azure Functions, ClaimsPrincipal.Current is not hydrated for .NET code, but you can still find the user claims in the request headers.

有关详细信息,请参阅访问用户声明For more information, see Access user claims.

令牌存储Token store

应用服务提供内置的令牌存储,这是与 Web 应用、API 或本机移动应用的用户相关联的令牌存储库。App Service provides a built-in token store, which is a repository of tokens that are associated with the users of your web apps, APIs, or native mobile apps. 对任何提供程序启用身份验证时,此令牌存储可立即供应用使用。When you enable authentication with any provider, this token store is immediately available to your app. 如果应用程序代码需要代表用户访问这些提供程序中的数据,例如:If your application code needs to access data from these providers on the user's behalf, such as:

  • 发布到经过身份验证的用户的 Facebook 时间线post to the authenticated user's Facebook timeline
  • 从 Azure Active Directory 图形 API 甚至 Microsoft Graph 中读取用户的企业数据read the user's corporate data from the Azure Active Directory Graph API or even the Microsoft Graph

通常,必须编写代码才能在应用程序中收集、存储和刷新这些令牌。You typically must write code to collect, store, and refresh these tokens in your application. 使用令牌存储,只需在需要令牌时才检索令牌;当令牌失效时,可以告知应用服务刷新令牌With the token store, you just retrieve the tokens when you need them and tell App Service to refresh them when they become invalid.

为经过身份验证的会话缓存的 ID 令牌、访问令牌和刷新令牌,只能由关联的用户访问。The id tokens, access tokens, and refresh tokens cached for the authenticated session, and they're accessible only by the associated user.

如果不需要在应用中使用令牌,可以禁用令牌存储。If you don't need to work with tokens in your app, you can disable the token store.

日志记录和跟踪Logging and tracing

如果启用应用程序日志记录,将在日志文件中直接看到身份验证和授权跟踪。If you enable application logging, you will see authentication and authorization traces directly in your log files. 如果出现意外的身份验证错误,查看现有的应用程序日志即可方便找到所有详细信息。If you see an authentication error that you didn’t expect, you can conveniently find all the details by looking in your existing application logs. 如果启用失败请求跟踪,可以确切地查看身份验证和授权模块在失败请求中发挥的作用。If you enable failed request tracing, you can see exactly what role the authentication and authorization module may have played in a failed request. 在跟踪日志中,找到对名为 EasyAuthModule_32/64 的模块的引用。In the trace logs, look for references to a module named EasyAuthModule_32/64.

标识提供者Identity providers

应用服务使用联合标识,在其中,第三方标识提供者会自动管理用户标识和身份验证流。App Service uses federated identity, in which a third-party identity provider manages the user identities and authentication flow for you. 默认提供五个标识提供者:Five identity providers are available by default:

提供商Provider 登录终结点Sign-in endpoint
Azure Active DirectoryAzure Active Directory /.auth/login/aad
Microsoft 帐户Microsoft Account /.auth/login/microsoftaccount
FacebookFacebook /.auth/login/facebook
GoogleGoogle /.auth/login/google
TwitterTwitter /.auth/login/twitter

对其中一个提供程序启用身份验证和授权时,其登录终结点可用于用户身份验证,以及验证来自提供程序的身份验证令牌。When you enable authentication and authorization with one of these providers, its sign-in endpoint is available for user authentication and for validation of authentication tokens from the provider. 可以轻松为用户提供其中任意数量的登录选项。You can provide your users with any number of these sign-in options with ease. 你还可以集成其他标识提供程序或你自己的自定义标识解决方案You can also integrate another identity provider or your own custom identity solution.

身份验证流Authentication flow

身份验证流对于所有提供程序是相同的,但根据是否要使用提供程序的 SDK 登录而有所差别:The authentication flow is the same for all providers, but differs depending on whether you want to sign in with the provider's SDK:

  • 不使用提供程序 SDK:应用程序向应用服务委托联合登录。Without provider SDK: The application delegates federated sign-in to App Service. 浏览器应用通常采用此方案,这可以防止向用户显示提供程序的登录页。This is typically the case with browser apps, which can present the provider's login page to the user. 服务器代码管理登录过程,因此,此流也称为“服务器导向流”或“服务器流”。The server code manages the sign-in process, so it is also called server-directed flow or server flow. 此方案适用于浏览器应用。This case applies to browser apps. 它也适用于使用移动应用客户端 SDK 登录用户的本机应用,因为 SDK 会打开 Web 视图,使用应用服务身份验证将用户登录。It also applies to native apps that sign users in using the Mobile Apps client SDK because the SDK opens a web view to sign users in with App Service authentication.
  • 使用提供程序 SDK:应用程序手动将用户登录到提供程序,然后将身份验证令牌提交给应用服务进行验证。With provider SDK: The application signs users in to the provider manually and then submits the authentication token to App Service for validation. 无浏览器应用通常采用此方案,这可以防止向用户显示提供程序的登录页。This is typically the case with browser-less apps, which can't present the provider's sign-in page to the user. 应用程序代码管理登录过程,因此,此流也称为“客户端导向流”或“客户端流”。The application code manages the sign-in process, so it is also called client-directed flow or client flow. 此方案适用于 REST API、Azure Functions 和 JavaScript 浏览器客户端,以及在登录过程中需要更高灵活性的浏览器应用。This case applies to REST APIs, Azure Functions, and JavaScript browser clients, as well as browser apps that need more flexibility in the sign-in process. 它还适用于使用提供程序 SDK 登录用户的本机移动应用。It also applies to native mobile apps that sign users in using the provider's SDK.

备注

可以使用服务器导向流,对来自应用服务中受信任浏览器应用的调用,或者来自应用服务或 Azure Functions 中另一 REST API 的调用进行身份验证。Calls from a trusted browser app in App Service calls another REST API in App Service or Azure Functions can be authenticated using the server-directed flow. 有关详细信息,请参阅在应用服务中自定义身份验证和授权For more information, see Customize authentication and authorization in App Service.

下表说明了身份验证流的步骤。The table below shows the steps of the authentication flow.

步骤Step 不使用提供程序 SDKWithout provider SDK 使用提供程序 SDKWith provider SDK
1.将用户登录1. Sign user in 将客户端重定向到 /.auth/login/<provider>Redirects client to /.auth/login/<provider>. 客户端代码直接使用提供程序的 SDK 将用户登录,并接收身份验证令牌。Client code signs user in directly with provider's SDK and receives an authentication token. 有关详细信息,请参阅提供程序文档。For information, see the provider's documentation.
2.身份验证后2. Post-authentication 提供程序将客户端重定向到 /.auth/login/<provider>/callbackProvider redirects client to /.auth/login/<provider>/callback. 客户端代码将来自提供程序的令牌发布到 /.auth/login/<provider> 进行验证。Client code posts token from provider to /.auth/login/<provider> for validation.
3.建立经过身份验证的会话3. Establish authenticated session 应用服务将经过身份验证的 Cookie 添加到响应中。App Service adds authenticated cookie to response. 应用服务将自身的身份验证令牌返回给客户端代码。App Service returns its own authentication token to client code.
4.提供经过身份验证的内容4. Serve authenticated content 客户端在后续请求中包含身份验证 Cookie(由浏览器自动处理)。Client includes authentication cookie in subsequent requests (automatically handled by browser). 客户端代码在 X-ZUMO-AUTH 标头中提供身份验证令牌(由移动应用客户端 SDK 自动处理)。Client code presents authentication token in X-ZUMO-AUTH header (automatically handled by Mobile Apps client SDKs).

对于客户端浏览器,应用服务可自动将所有未经身份验证的用户定向到 /.auth/login/<provider>For client browsers, App Service can automatically direct all unauthenticated users to /.auth/login/<provider>. 还可以向用户提供一个或多个 /.auth/login/<provider> 链接,让他们使用所选的提供程序登录到你的应用。You can also present users with one or more /.auth/login/<provider> links to sign in to your app using their provider of choice.

授权行为Authorization behavior

Azure 门户中, 当传入请求未经过身份验证时, 你可以使用多种行为配置应用服务授权。In the Azure portal, you can configure App Service authorization with a number of behaviors when incoming request is not authenticated.

以下标题介绍了选项。The following headings describe the options.

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

此选项会将未经身份验证的流量授权到你的应用程序代码。This option defers authorization of unauthenticated traffic to your application code. 对于经过身份验证的请求,应用服务还会在 HTTP 标头中一起传递身份验证信息。For authenticated requests, App Service also passes along authentication information in the HTTP headers.

使用此选项可以更灵活地处理匿名请求。This option provides more flexibility in handling anonymous requests. 例如,可以向用户提供多个登录提供程序For example, it lets you present multiple sign-in providers to your users. 但是,必须编写代码。However, you must write code.

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

选项为“使用 <提供程序> 登录”。The option is Log in with <provider>. 应用服务将所有匿名请求重定向到所选提供程序的 /.auth/login/<provider>App Service redirects all anonymous requests to /.auth/login/<provider> for the provider you choose. 如果匿名请求来自本机移动应用,则返回的响应为 HTTP 401 UnauthorizedIf the anonymous request comes from a native mobile app, the returned response is an HTTP 401 Unauthorized.

使用此选项不需要在应用中编写任何身份验证代码。With this option, you don't need to write any authentication code in your app. 可以通过检查用户的声明来处理精细授权,例如角色特定的授权(请参阅访问用户声明)。Finer authorization, such as role-specific authorization, can be handled by inspecting the user's claims (see Access user claims).

注意

以这种方式限制访问权限适用于对应用的所有调用, 对于需要公开提供的主页的应用, 与在许多单页应用程序中一样。Restricting access in this way applies to all calls to your app, which may not be desirable for apps wanting a publicly available home page, as in many single-page applications.

更多资源More resources

教程:在 Azure 应用服务 (Windows) 中对用户进行端到端身份验证和授权Tutorial: Authenticate and authorize users end-to-end in Azure App Service (Windows)
教程:在适用于 Linux 的 Azure 应用服务中对用户进行端到端身份验证和授权Tutorial: Authenticate and authorize users end-to-end in Azure App Service for Linux
在应用服务中自定义身份验证和授权Customize authentication and authorization in App Service

特定于提供程序的操作方法指南:Provider-specific how-to guides: