什么是身份验证？

身份验证 是要求一方使用合法凭据的行为，为创建用于标识和访问控制的安全主体提供了依据。 简单来说，就是证明你就是你所说的那个人的过程。 身份验证有时缩写为 AuthN。

授权 是授予经过身份验证的安全主体执行某些作的权限的行为。 它规定了您可以访问哪些数据，以及可以对这些数据执行什么操作。 授权有时缩写为 AuthZ。

面向开发人员的 Azure Active Directory（v1.0）（Azure AD）通过提供标识即服务，支持行业标准协议（如 OAuth 2.0 和 OpenID Connect）以及适用于不同平台的开源库，帮助你快速开始编码，从而简化应用程序开发人员的身份验证。

Azure AD 编程模型中有两个主要用例：

• 在 OAuth 2.0 授权流期间 - 当资源所有者向客户端应用程序授予授权时，允许客户端访问资源所有者的资源。
• 在客户端访问资源期间，由资源服务器实施访问控制，使用访问令牌中的声明值来制定访问控制决策。

Azure AD 中的身份验证基础知识

考虑需要标识的最基本方案：Web 浏览器中的用户需要向 Web 应用程序进行身份验证。 下图显示了此方案：

下面是有关关系图中显示的各种组件需要了解的内容：

• Azure AD 是标识提供者。 标识提供者负责验证组织目录中存在的用户和应用程序的标识，并在成功对这些用户和应用程序进行身份验证时颁发安全令牌。
• 要将身份验证外包给 Azure AD 的应用程序必须在 Azure Active Directory（Azure AD）中注册。 Azure AD 注册并唯一标识目录中的应用。
• 开发人员可以使用开源 Azure AD 身份验证库，通过为你处理协议详细信息，轻松进行身份验证。 有关详细信息，请参阅Microsoft标识平台 v2.0 身份验证库 和 v1.0 身份验证库。
• 用户进行身份验证后，应用程序必须验证用户的安全令牌，以确保身份验证成功。 可以在各种语言和框架中找到快速入门、教程和代码示例，这些示例显示了应用程序必须执行的作。
  • 若要快速生成应用并添加功能，例如获取令牌、刷新令牌、登录用户、显示一些用户信息等，请参阅文档的 快速入门 部分。
  • 要深入了解用于顶级身份验证开发人员任务（如获取访问令牌并在调用 Microsoft Graph API 及其他 API 时使用这些令牌）的具体步骤，请参阅文档中的 “教程” 部分。该部分还包括如何通过基于 Web 浏览器的传统应用程序使用 OpenID Connect 实现 Microsoft 登录等内容。
  • 若要下载代码示例，请转到 GitHub。
• 身份验证过程的请求和响应流取决于所使用的身份验证协议，例如 OAuth 2.0、OpenID Connect、WS 联合身份验证或 SAML 2.0。 有关协议的详细信息，请参阅文档的 “ > 概念身份验证协议 ”部分。

在上面的示例方案中，可以根据以下两个角色对应用进行分类：

• 需要安全访问资源的应用
• 扮演资源本身角色的应用

每个流如何发出令牌和代码

根据客户端的生成方式，它可以使用 Azure AD 支持的身份验证流的一个（或几个）。 这些流可以生成各种令牌（id_tokens、刷新令牌、访问令牌）以及授权代码，并且需要不同的令牌才能使其正常工作。 此图表提供概述：

通过隐式模式颁发的令牌由于通过 URL 返回到浏览器，这导致令牌有长度限制，其中 response_mode 可以是 query 或 fragment。 某些浏览器对可以放入浏览器栏中的 URL 长度有限制，当 URL 太长时会导致错误。 因此，这些令牌没有 groups 或 wids 声明。

了解基础知识后，请继续阅读以了解标识应用模型和 API、Azure AD 中的预配工作原理，以及有关 Azure AD 支持的常见方案的详细信息的链接。

应用程序模型

Azure AD 表示遵循特定模型的应用程序，该模型旨在实现两个主要功能：

• 根据它支持的身份验证协议标识应用 - 这涉及到枚举身份验证时所需的所有标识符、URL、机密和相关信息。 此处，Azure AD：

  • 保存在运行时支持身份验证所需的所有数据。
  • 保存所有数据，用于确定应用可能需要访问哪些资源，以及给定请求是否应满足，以及在这种情况下。
  • 提供用于在应用开发人员租户和任何其他 Azure AD 租户中实现应用预配的基础结构。

• 在令牌请求期间处理用户同意，并有助于跨租户动态预配应用 - 此处为 Azure AD：

  • 使用户和管理员能够动态授予或拒绝应用代表其访问资源的同意。
  • 使管理员能够最终决定允许哪些应用以及哪些用户可以使用特定应用，以及访问目录资源的方式。

在 Azure AD 中， 应用程序对象 将应用程序描述为抽象实体。 开发人员与应用程序一起工作。 在部署时，Azure AD 使用给定的应用程序对象作为蓝图来创建 服务主体，该主体表示目录或租户中应用程序的具体实例。 它是服务主体，用于定义应用在特定目标目录中实际可以执行的作、谁可以使用它、有权访问的资源，等等。 Azure AD 通过 同意从应用程序对象创建服务主体。

下图显示了由许可驱动的简化的 Azure AD 预配流。 其中存在两个租户（A 和 B），其中租户 A 拥有应用程序，租户 B 通过服务主体实例化应用程序。

在此预配流中：

1. 租户 B 中的用户尝试使用应用登录，授权终结点会请求应用程序的令牌。
2. 获取并验证用户凭据以进行身份验证
3. 用户会收到提示给予同意以便应用获取租户 B 的访问权限
4. Azure AD 使用租户 A 中的应用程序对象作为在租户 B 中创建服务主体的蓝图
5. 用户收到请求的令牌

可以根据需要为其他租户重复此过程（C、D 等）。 租户 A 保留应用（应用程序对象）的蓝图。 那些授予应用权限的其他租户中的用户和管理员可以通过每个租户中的相应服务主体对象来控制应用程序被允许执行的操作。 有关详细信息，请参阅 Microsoft标识平台中的应用程序和服务主体对象。

Azure AD 安全令牌中的声明

Azure AD 颁发的安全令牌 (访问和 ID 令牌) 包含有关经过身份验证的主体的信息声明或断言。 应用程序可以将声明用于各种任务，包括：

• 验证令牌
• 识别主题的目录租户
• 显示用户信息
• 确定对象的授权

任何给定安全令牌中存在的声明都取决于令牌的类型、用于对用户进行身份验证的凭据类型和应用程序配置。

下表提供了 Azure AD 发出的每种声明的简要说明。 有关详细信息，请参阅 Azure AD 颁发的 访问令牌 和 ID 令牌 。

后续步骤

• 了解 Microsoft标识平台中支持的应用程序类型和方案