身份验证基础知识Authentication basics

什么是身份验证What is authentication

本文解释在创建受保护的 Web 应用、Web API 或创建调用受保护 Web API 的应用时需要了解的许多身份验证概念。This article covers many of the authentication concepts you'll need to understand to create protected web apps, web APIs, or apps calling protected Web APIs.

身份验证就是证明自己的身份的过程。Authentication is the process of proving you are who you say you are. 身份验证有时缩写为 AuthN。Authentication is sometimes shortened to AuthN.

授权是指授予经过身份验证的一方执行某项操作的权限的措施。Authorization is the act of granting an authenticated party permission to do something. 它指定了你可以访问的数据,以及可对该数据执行的操作。It specifies what data you're allowed to access and what you can do with that data. 授权有时缩写为 AuthZ。Authorization is sometimes shortened to AuthZ.

无需创建每个需要维护自身用户名和密码信息的应用(需要在多个应用中添加或删除用户时,这会产生较高的管理负担),而可以让应用将这种责任委托给一个集中式标识提供者。Instead of creating apps that each maintain their own username and password information, which incurs a high administrative burden when you need to add or remove users across multiple apps, apps can delegate that responsibility to a centralized identity provider.

Azure Active Directory (Azure AD) 是云中的集中式标识提供者。Azure Active Directory (Azure AD) is a centralized identify provider in the cloud. 向其委托身份验证和授权可以实现要求用户位于特定位置的方案、使用多重身份验证,并可让用户登录一次,然后自动登录到共享同一集中式目录的所有 Web 应用。Delegating authentication and authorization to it enables scenarios that require a user to be in a specific location, the use of multi-factor authentication, as well as enabling a user to sign in once and then be automatically signed in to all of the web apps that share the same centralized directory. 此功能称为单一登录 (SSO)。This capability is referred to as Single Sign On (SSO).

对于用户位于全球各地,且用户不一定从企业网络登录的应用而言,集中式标识提供者更为重要。A centralized identity provider is even more important for apps that have users located around the globe that don't necessarily sign in from the enterprise's network. Azure AD 将对用户进行身份验证并提供访问令牌。Azure AD authenticates users and provides access tokens. 访问令牌是授权服务器颁发的安全令牌。An access token is a security token that is issued by an authorization server. 其中包含有关该令牌所针对的用户和应用的信息,可用于访问 Web API 和其他受保护资源。It contains information about the user and the app for which the token is intended, which can be used to access Web APIs and other protected resources.

Microsoft 标识平台通过以下方式简化了对应用程序开发人员的身份验证:将标识提供为一项服务、支持行业标准协议(例如 OAuth 2.0 和 OpenID Connect),并提供用于不同平台的开源库来帮助你快速开始编写代码。The Microsoft identity platform simplifies authentication for application developers by providing identity as a service, with support for industry-standard protocols such as OAuth 2.0 and OpenID Connect, as well as open-source libraries for different platforms to help you start coding quickly. 开发人员可以通过它来生成应用程序,以便进行所有 Microsoft 标识的登录,以及获取令牌来调用 Microsoft Graph、其他 Microsoft API 或者开发人员生成的 API。It allows developers to build applications that sign in all Microsoft identities, get tokens to call Microsoft Graph, other Microsoft APIs, or APIs that developers have built. 有关详细信息,请参阅 Microsoft 标识平台的发展For more information, see Evolution of Microsoft identity platform.

租户Tenants

云标识提供者为许多组织提供服务。A cloud identity provider serves many organizations. 为使不同组织中的用户保持隔离,Azure AD 已分区成租户,每个组织有一个租户。To keep users from different organizations separate, Azure AD is partitioned into tenants, with one tenant per organization.

租户跟踪用户及其关联的应用。Tenants keep track of users and their associated apps.

Azure AD 还提供 Azure Active Directory B2C,使组织能够使用社交标识将用户(通常是客户)登录。Azure AD also provides Azure Active Directory B2C so that organizations can sign in users, typically customers, using social identities. 有关详细信息,请参阅 Azure Active Directory B2C 文档For more information, see Azure Active Directory B2C documentation .

安全令牌Security tokens

安全令牌包含有关用户和应用的信息。Security tokens contain information about users and apps. Azure AD 使用包含声明的基于 JSON 的令牌 (JWT)。Azure AD uses JSon based tokens (JWTs) that contain claims. 声明向一个实体提供有关另一个实体的断言。A claim provides assertions about one entity to another. 应用程序可以使用声明来完成各种任务,例如:Applications can use claims for various tasks such as:

  • 验证令牌Validating the token
  • 识别使用者的目录租户Identifying the subject's directory tenant
  • 显示用户信息Displaying user information
  • 确定使用者的授权Determining the subject's authorization

声明由提供如下信息的键值对组成:A claim consists of key-value pairs that provide information such as:

  • 生成令牌的安全令牌服务器。the Security Token Server that generated the token.
  • 令牌生成日期。the date when the token was generated.
  • 使用者,例如用户(守护程序除外)。the subject, such as the user (except for daemons).
  • 受众,即,为其生成了令牌的应用。the audience, which is the app for which the token was generated.
  • 请求令牌的应用(客户端)。the app (the client) that asked for the token. 对于 Web 应用,这可能与受众相同。In the case of web apps, this may be the same as the audience.

有关声明的更详细信息,请参阅访问令牌ID 令牌For more detailed claim information, see the access tokens and ID tokens.

由为其生成了令牌的应用、将登录用户的 Web 应用或所调用的 Web API 负责验证令牌。It's up to the app for which the token was generated, the web app that signed-in the user, or the Web API being called, to validate the token. 令牌由安全令牌服务器 (STS) 使用私钥签名。The token is signed by the Security Token Server (STS) with a private key. STS 发布相应的公钥。The STS publishes the corresponding public key. 若要验证令牌,应用需使用 STS 公钥验证签名,以验证签名是使用私钥创建的。To validate a token, the app verifies the signature by using the STS public key to validate that the signature was created using the private key.

令牌仅在有限的时间内有效。Tokens are only valid for a limited amount of time. 通常,STS 会提供一对令牌:一个用于访问应用程序或受保护资源的访问令牌,以及一个在访问令牌即将过期时用于刷新访问令牌的刷新令牌。Usually the STS provides a pair of tokens: an access token to access the application or protected resource, and a refresh token used to refresh the access token when the access token is close to expiring.

访问令牌作为 Authenticate 标头中的持有者令牌传递给 Web API。Access tokens are passed to a Web API as the bearer token in the Authenticate header. 应用可向 STS 提供刷新令牌,如果用户对应用的访问权限未吊销,则应用将取回新的访问令牌和新的刷新令牌。An app can provide a refresh token to the STS, and if the user access to the app wasn't revoked, it will get back a new access token and a new refresh token. 用户离职的场景就是这样处理的。This is how the scenario of someone leaving the enterprise is handled. 当 STS 收到刷新令牌时,如果用户不再获得授权,则 STS 不会颁发另一个有效的访问令牌。When the STS receives the refresh token, it won't issue another valid access token if the user is no longer authorized.

应用程序模型Application model

应用程序可以自行将用户登录,或者委托标识提供者登录。Applications can sign in users themselves or delegate sign-in to an identity provider. 有关 Azure AD 支持的登录方案,请参阅身份验证流和应用方案See Authentication flows and app scenarios to learn about sign-in scenarios supported by Azure AD.

要使标识提供者知道某个用户有权访问特定的应用,必须同时将该用户和应用程序注册到标识提供者。For an identity provider to know that a user has access to a particular app, both the user and the application must be registered with the identity provider. 将应用程序注册到 Azure AD 时,需要提供应用程序的标识配置,使其能够与 Azure AD 集成。When you register your application with Azure AD, you are providing an identity configuration for your application that allows it to integrate with Azure AD. 注册应用还可以:Registering the app also allows you to:

  • 在登录对话框中自定义应用程序的品牌。customize the branding of your application in the sign-in dialog. 这一点很重要,因为这是用户首次体验你的应用。This is important because this is the first experience a user will have with your app.
  • 确定是否只允许属于你的组织的用户登录。decide if you want to let users sign in only if they belong to your organization. 这是一个单租户应用程序。This is a single tenant application. 或者允许用户使用任何工作或学校帐户登录。Or allow users to sign in using any work or school account. 这是一个多租户应用程序。This is a multi-tenant application.
  • 请求范围权限。request scope permissions. 例如,可以请求“user.read”范围,该授予读取已登录用户的个人资料的权限。For example, you can request the "user.read" scope, which grants permission to read the profile of the signed-in user.
  • 定义范围,用于定义对 Web API 的访问权限。define scopes that define access to your Web API. 通常,当某个应用想要访问你的 API 时,它需要请求对你所定义的范围的权限。Typically, when an app wants to access your API, it will need to request permissions to the scopes you define.
  • 与 Azure AD 共享机密,以向 Azure AD 证明应用的标识。share a secret with Azure AD that proves the app's identity to Azure AD. 这适用于应用是机密客户端应用程序的情况。This is relevant in the case where the app is a confidential client application. 机密客户端应用程序是可以安全保存凭据的应用程序。A confidential client application is an application that can hold credentials securely. 它们需要使用受信任的后端服务器来存储凭据。They require a trusted backend server to store the credentials.

注册后,将为应用程序提供一个 GUID,应用在请求令牌时将与 Azure AD 共享该 GUID。Once registered, the application will be given a GUID that the app shares with Azure AD when it requests tokens. 如果应用是机密客户端应用程序,则它还会根据使用的是证书还是机密,来共享机密或公钥。If the app is a confidential client application, it will also share the secret or the public key, depending on whether certificates or secrets were used.

Microsoft 标识平台使用实现以下两项主要功能的模型来表示应用程序:The Microsoft identity platform represents applications using a model that fulfills two main functions:

按应用支持的身份验证协议来识别应用,并提供身份验证时所需的所有标识符、URL、机密和相关信息。Identify the app by the authentication protocols it supports and provide all the identifiers, URLs, secrets, and related information that are needed to authenticate. Microsoft 标识平台:The Microsoft identity platform:

  • 保存运行时支持身份验证所需的所有数据。Holds all the data required to support authentication at runtime.
  • 保存所有数据,以确定应用可能需要访问的资源,以及在哪些情况下应满足给定的请求。Holds all the data for deciding what resources an app might need to access, and under what circumstances a given request should be fulfilled.
  • 提供用于在应用开发人员的租户和任何其他 Azure AD 租户中实现应用配置的基础设施。Provides infrastructure for implementing app provisioning within the app developer's tenant, and to any other Azure AD tenant.

在请求令牌期间处理用户许可,并简化各个租户中的应用动态预配。“许可”是资源所有者授权客户端应用程序使用特定的权限代表资源所有者访问受保护资源的过程。Handle user consent during token request time and facilitate the dynamic provisioning of apps across tenants Consent is the process of a resource owner granting authorization to a client application to access protected resources, under specific permissions, on behalf of the resource owner. Microsoft 标识平台:The Microsoft identity platform:

  • 使用户和管理员能够动态地同意或拒绝应用以他们的名义访问资源。Enables users and administrators to dynamically grant or deny consent for the app to access resources on their behalf.
  • 使管理员能够最终决定允许执行哪些应用、哪些用户可以使用特定的应用,以及如何访问目录资源。Enables administrators to ultimately decide what apps are allowed to do and which users can use specific apps, and how the directory resources are accessed.

在 Microsoft 标识平台中,应用程序对象将应用程序描述为抽象实体。In the Microsoft identity platform, an application object describes an application as an abstract entity. 在部署时,Microsoft 标识平台使用应用程序对象作为蓝图来创建服务主体,它表示目录或租户中的应用程序的具体实例。At deployment time, the Microsoft identity platform uses the application object as a blueprint to create a service principal, which represents a concrete instance of an application within a directory or tenant. 该服务主体定义应用在特定目标目录中可以实际执行的操作、使用者是谁、以及可以访问哪些资源等。The service principal defines what the app can actually do in a specific target directory, who can use it, what resources it has access to, and so on. Microsoft 标识平台通过许可使用应用程序对象创建服务主体。The Microsoft identity platform creates a service principal from an application object through consent.

下图显示了征得同意后经过简化的 Microsoft 标识平台预配流程。The following diagram shows a simplified Microsoft identity platform provisioning flow driven by consent. 它显示两个租户(A 和 B)。It shows two tenants (A and B). 租户 A 拥有该应用程序。Tenant A owns the application. 租户 B 通过服务主体实例化该应用程序。Tenant B is instantiating the application via a service principal.

征得同意后经过简化的预配流程

在此预配流程中:In this provisioning flow:

  1. 来自租户 B 的某个用户尝试使用该应用登录,授权终结点请求应用程序的令牌。A user from tenant B attempts to sign in with the app, the authorization endpoint requests a token for the application.
  2. 获取并验证用于身份验证的用户凭据。The user credentials are acquired and verified for authentication.
  3. 系统提示用户许可该应用访问租户 B。The user is prompted to provide consent for the app to gain access to tenant B.
  4. Microsoft 标识平台使用租户 A 中的应用程序对象作为在租户 B 中创建服务主体的蓝图。The Microsoft identity platform uses the application object in tenant A as a blueprint for creating a service principal in tenant B.
  5. 用户接收请求的令牌。The user receives the requested token.

可对其他租户重复此过程。You can repeat this process for additional tenants. 租户 A 保留了应用(应用程序对象)的蓝图。Tenant A retains the blueprint for the app (application object). 应用获得许可的所有其他租户中的用户和管理员通过每个租户中的相应服务主体对象保留对应用程序允许执行的操作的控制权。Users and admins of all the other tenants where the app is given consent keep control over what the application is allowed to do via the corresponding service principal object in each tenant. 有关详细信息,请参阅 Microsoft 标识平台中的应用程序和服务主体对象For more information, see Application and service principal objects in Microsoft identity platform.

使用 Azure AD 的 Web 应用登录流Web app sign-in flow with Azure AD

当用户在浏览器中导航到某个 Web 应用时,将发生以下情况:When a user navigates in the browser to a web app, the following happens:

  • Web 应用确定用户是否已完成身份验证。The web app determines whether the user is authenticated.
  • 如果用户未完成身份验证,Web 应用将委托 Azure AD 将用户登录。If the user isn't authenticated, the web app delegates to Azure AD to sign in the user. 登录符合组织的策略,这可能意味着,系统会要求用户输入其凭据、使用多重身份验证,或者完全禁止使用密码(例如使用 Windows Hello)。That sign in will be compliant with the policy of the organization, which may mean asking the user to enter their credentials, using multi-factor-authentication, or not using a password at all (for example using Windows Hello).
  • 系统要求用户许可客户端应用所需的访问权限。The user is asked to consent to the access that the client app needs. 正因如此,需要在 Azure AD 中注册客户端应用,使 Azure AD 能够传送代表用户许可的访问权限的令牌。This is why client apps need to be registered with Azure AD, so that Azure AD can deliver tokens representing the access that the user has consented to.

用户成功完成身份验证后:When the user has successfully authenticated:

  • Azure AD 将令牌发送到 Web 应用。Azure AD sends a token to the web app.
  • 保存与 Azure AD 的域关联的 Cookie,其中包含浏览器 Cookie jar 中的用户标识。A cookie is saved, associated with Azure AD's domain, that contains the identity of the user in the browser's cookie jar. 下次应用使用浏览器导航到 Azure AD 授权终结点时,浏览器将提供该 Cookie,因此用户无需再次登录。The next time an app uses the browser to navigate to the Azure AD authorization end point, the browser presents the cookie so that the user doesn't have to sign in again. 这也是实现 SSO 的方式。This is also the way that SSO is achieved. Cookie 由 Azure AD 生成,只有 Azure AD 能够识别它。The cookie is produced by Azure AD and can only be understood by Azure AD.
  • 然后,Web 应用验证令牌。The web app then validates the token. 如果验证成功,Web 应用将显示受保护的页,并在浏览器的 Cookie jar 中保存会话 Cookie。If the validation succeeds, the web app displays the protected page and saves a session cookie in the browser's cookie jar. 当用户导航到另一页时,Web 应用知道用户已基于会话 Cookie 进行身份验证。When the user navigates to another page, the web app knows that the user is authenticated based on the session cookie.

以下序列图汇总了这种交互:The following sequence diagram summarizes this interaction:

Web 应用身份验证过程

Web 应用如何确定用户是否已完成身份验证How a web app determines if the user is authenticated

Web 应用开发人员可以指定是所有页还是只有特定的页需要身份验证。Web app developers can indicate whether all or only certain pages require authentication. 例如,在 ASP.NET/ASP.NET Core 中,可以通过将 [Authorize] 属性添加到控制器操作来进行这种指定。For example, in ASP.NET/ASP.NET Core, this is done by adding the [Authorize] attribute to the controller actions.

此属性会导致 ASP.NET 检查是否存在包含用户标识的会话 Cookie。This attribute causes ASP.NET to check for the presence of a session cookie containing the identity of the user. 如果 Cookie 不存在,ASP.NET 会将身份验证重定向到指定的标识提供者。If a cookie isn't present, ASP.NET redirects authentication to the specified identity provider. 如果标识提供者是 Azure AD,则 Web 应用会将身份验证重定向到 https://login.partner.microsoftonline.cn ,这会显示登录对话框。If the identity provider is Azure AD, the web app redirects authentication to https://login.partner.microsoftonline.cn, which displays a sign-in dialog.

Web 应用如何将登录委托给 Azure AD 和获取令牌How a web app delegates sign-in to Azure AD and obtains a token

用户身份验证通过浏览器发生。User authentication happens via the browser. OpenID 协议使用标准 HTTP 协议消息。The OpenID protocol uses standard HTTP protocol messages.

  • Web 应用将 HTTP 202(重定向)发送到浏览器以使用 Azure AD。The web app sends an HTTP 202 (redirect) to the browser to use Azure AD.
  • 对用户进行身份验证时,Azure AD 通过浏览器使用重定向将令牌发送到 Web 应用。When the user is authenticated, Azure AD sends the token to the web app by using a redirect through the browser.
  • 重定向由 Web 应用以重定向 URI 的形式提供。The redirect is provided by the web app in the form of a redirect URI. 此重定向 URI 将注册到 Azure AD 应用程序对象。This redirect URI is registered with the Azure AD application object. 由于应用程序可部署到多个 URL,可能存在多个重定向 URI。There can be several redirect URIs because the application may be deployed at several URLs. 因此,Web 应用还需要指定要使用的重定向 URI。So the web app will also need to specify the redirect URi to use.
  • Azure AD 验证 Web 应用发送的重定向 URI 是否为应用的已注册重定向 URI 之一。Azure AD verifies that the redirect URI sent by the web app is one of the registered redirect URIs for the app.

使用 Azure AD 的桌面和移动应用登录流Desktop and mobile app sign-in flow with Azure AD

上面所述的流适用于桌面和移动应用程序,只是存在少许差异。The flow described above applies, with slight differences, to desktop and mobile applications.

桌面和移动应用程序可以使用嵌入式 Web 控件或系统浏览器进行身份验证。Desktop and mobile applications can use an embedded Web control, or a system browser, for authentication. 下图演示了桌面或移动应用如何使用 Microsoft 身份验证库 (MSAL) 获取访问令牌和调用 Web API。The following diagram shows how a Desktop or mobile app uses the Microsoft authentication library (MSAL) to acquire access tokens and call web APIs.

桌面应用的身份验证方式

MSAL 使用浏览器获取令牌,与对 Web 应用一样,将身份验证委托给 Azure AD。MSAL uses a browser to get tokens, and as with web apps, delegates authentication to Azure AD.

由于 Azure AD 与对 Web 应用一样在浏览器中保存相同的标识 Cookie,因此,如果本机应用或移动应用使用系统浏览器,则会立即在相应的 Web 应用上实现 SSO。Because Azure AD saves the same identity cookie in the browser as it does for web apps, if the native or mobile app uses the system browser it will immediately get SSO with the corresponding web app.

默认情况下,MSAL 使用系统浏览器,但 .NET Framework 桌面应用程序除外,其中使用嵌入式控件来提供集成程度更高的用户体验。By default, MSAL uses the system browser except for .NET Framework desktop applications where an embedded control is used to provide a more integrated user experience.

后续步骤Next steps

请参阅 Microsoft 标识平台开发人员术语表来熟悉常用术语。See the Microsoft identity platform developer glossary to get familiar with common terms. 请参阅身份验证流和应用方案来详细了解 Microsoft 标识平台支持的其他用户身份验证方案。See Authentication flows and app scenarios to learn more about other scenarios for authenticating users supported by the Microsoft identity platform. 请参阅 MSAL 库,了解可以借助哪些 Microsoft 库在单个简化编程模型中开发可以处理 Azure AD 帐户和 Azure AD B2C 用户的应用程序。See MSAL libraries to learn about the Microsoft libraries that help you develop applications that work with Azure AD accounts, and Azure AD B2C users all in a single, streamlined programming model.