通过

Azure Active Directory v1.0 终结点中的权限和许可

警告

本内容适用于较旧版本的 Azure AD v1.0 终结点。 为新项目使用 Microsoft 标识平台。

Azure Active Directory （Azure AD）对 OAuth 和 OpenID Connect （OIDC） 流使用大量权限。 当应用从 Azure AD 收到访问令牌时，访问令牌将包含描述应用对特定资源的权限的声明。

权限（也称为 范围）使资源的授权变得简单，因为资源只需检查令牌是否包含应用程序所调用 API 的相应权限。

权限类型

Azure AD 定义两种类型的权限：

  • 委派的权限 - 由具有登录用户的应用使用。 对于这些应用，用户或管理员同意应用所请求的权限，并且应用在调用 API 时被授予权限，以登录用户的身份进行操作。 根据 API，用户可能无法直接同意 API，而是 要求管理员提供“管理员同意”。
  • 应用程序权限 - 由在没有登录用户的情况下运行的应用使用;例如，作为后台服务或守护程序运行的应用。 应用程序权限只能由管理员批准 ，因为它们通常涉及较高的权限等级，并且允许跨用户边界访问数据，或访问通常仅限于管理员的数据。 被定义为资源应用程序所有者的用户（即发布权限的 API）也被允许为他们拥有的 API 授予应用程序权限。

有效权限是应用在向 API 发出请求时拥有的权限。

  • 对于委派权限，应用的有效权限将是应用在用户同意后授予的委派权限与当前登录用户权限之间的最小权限交集。 应用的特权永远不会超过登录用户的特权。 在组织中，登录用户的特权可以由策略或一个或多个管理员角色的成员身份决定。 若要了解哪些管理员角色可以同意委派权限，请参阅 Azure AD 中的管理员角色权限。 例如，假设应用已在 Microsoft Graph 中被授予 User.ReadWrite.All 委派权限。 此权限在名义上会授予应用读取和更新组织中每个用户的个人资料的权限。 如果登录用户是全局管理员，则应用可以更新组织中每个用户的个人资料。 但是，如果登录用户不是充当管理员角色，则应用只能更新登录用户的个人资料。 它无法更新组织中其他用户的个人资料，因为该应用有权代表的用户没有这些特权。
  • 对于应用程序权限，应用的有效权限是权限隐含的完全权限级别。 例如，具有 User.ReadWrite.All 应用程序权限的应用可以更新组织中的每个用户的配置文件。

权限属性

Azure AD 中的权限具有许多属性，可帮助用户、管理员或应用开发人员做出有关权限授予访问权限的明智决策。

注释

可以使用 Azure 门户或 PowerShell 查看 Azure AD 应用程序或服务主体公开的权限。 尝试使用此脚本查看 Microsoft Graph 公开的权限。

Connect-AzureAD

# Get OAuth2 Permissions/delegated permissions
(Get-AzureADServicePrincipal -filter "DisplayName eq 'Microsoft Graph'").OAuth2Permissions

# Get App roles/application permissions
(Get-AzureADServicePrincipal -filter "DisplayName eq 'Microsoft Graph'").AppRoles
属性名称 说明 示例
ID 唯一标识此权限的 GUID 值。 570282fd-fa5c-430d-a7fd-fc8dc98a9dca
IsEnabled 指示此权限是否可供使用。 是
Type 指示此权限是否需要用户同意或管理员同意。 用户
AdminConsentDescription 管理员同意体验期间向管理员显示的说明 允许应用在用户邮箱中读取电子邮件。
AdminConsentDisplayName 管理员同意体验期间向管理员显示的友好名称。 读取用户邮件
UserConsentDescription 在用户同意体验期间向用户显示的说明。 允许应用在邮箱中读取电子邮件。
UserConsentDisplayName 在用户同意过程中向用户显示的友好名称。 阅读邮件
Value 用于在 OAuth 2.0 授权流期间标识权限的字符串。 Value 也可以与应用 ID URI 字符串结合使用，以形成完全限定的权限名称。 Mail.Read

Azure AD 中的应用程序依赖许可来获取对所需资源或 API 的访问权限。 你的应用可能需要了解多种同意才能成功。 如果要定义权限，则还需要了解用户如何获取对应用或 API 的访问权限。

  • 静态用户同意 - 在指定应用要与之交互的资源时，OAuth 2.0 授权流 自动发生。 在静态用户同意方案中，应用必须已指定在 Azure 门户中应用配置中所需的所有权限。 如果用户（或管理员）未为此应用授予许可，则 Azure AD 将提示用户此时提供同意。

    详细了解如何注册请求访问静态 API 集的 Azure AD 应用。

  • 动态用户同意 - v2 Azure AD 应用模型的功能。 在此场景中，你的应用请求了一组权限，这是 v2 应用 在OAuth 2.0 授权流中所需的。 如果用户尚未同意，则此时会提示他们同意。 详细了解动态同意。

    重要

    动态许可可能十分方便，但对于需要管理员同意的权限而言，仍然存在巨大的挑战，因为在达成同意的时点，管理员的同意体验并不了解这些权限。 如果你需要管理员特权权限，或者应用使用动态许可，则必须在 Azure 门户中注册所有权限（而不仅仅是需要管理员同意的权限子集）。 这使租户管理员能够代表其所有用户同意。

  • 管理员同意 - 当应用需要访问某些高特权权限时，是必需的。 管理员同意可确保管理员在授权应用或用户访问来自组织的高特权数据之前具有一些其他控制措施。 详细了解如何授予管理员同意。

最佳做法

客户端最佳做法

  • 仅请求应用所需的权限。 权限过多的应用如果被攻破，就有泄露用户数据的风险。
  • 根据应用支持的方案在委派权限和应用程序权限之间进行选择。
    • 如果代表用户进行调用，请始终使用委派权限。
    • 仅当应用是非交互式应用且不代表任何特定用户进行调用时，才使用应用程序权限。 应用程序权限具有很高的特权，仅当绝对必要时才应使用。
  • 基于 v2.0 终结点使用应用时，始终将静态权限（在应用程序注册中指定的权限）设置为运行时请求的动态权限的超集（在代码中指定的权限并在授权请求中作为查询参数发送），以便管理员同意等方案正常工作。

资源/API 最佳实践

  • 公开 API 的资源应定义特定于其保护的数据或作的权限。 遵循此最佳做法有助于确保客户端最终无权访问他们不需要的数据，并告知用户同意哪些数据。
  • 资源应分别显式定义 Read 和 ReadWrite 权限。
  • 资源应将允许跨用户边界访问数据的任何权限标记为 Admin 权限。
  • 资源应遵循 Subject.Permission[.Modifier]命名模式，其中：

    • Subject 对应于可用的数据类型

    • Permission 对应于用户可能对该数据执行的操作

    • Modifier 可选地用于描述另一个权限的专用化

      例如：

    • Mail.Read - 允许用户阅读邮件。

    • Mail.ReadWrite - 允许用户读取或写入邮件。

    • Mail.ReadWrite.All - 允许管理员或用户访问组织中的所有邮件。