通过

Microsoft Entra ID 中应用程序的同意体验

  • 项目

本文将介绍 Microsoft Entra 的应用程序同意用户体验。 可以通过更加无缝的许可体验，智能地管理组织的应用程序和/或开发应用程序。

许可是指用户授权应用程序代表他们访问受保护资源的过程。 可以要求管理员或用户同意访问其组织/个人数据。

给予同意的实际用户体验将因用户租户上设置的策略、用户的授权范围（或角色）以及客户端应用程序请求的权限类型而异。 这意味着应用程序开发人员和租户管理员可以对许可体验进行一些控制。 管理员可以在租户或应用上灵活地设置和禁用策略，以控制其租户中的许可体验。 应用程序开发人员可以指示正在请求的访问权限类型以及是否希望引导用户完成用户同意流或管理员同意流。

  • 用户许可流是指应用程序开发人员将用户定向到授权终结点，意图仅记录当前用户的许可。
  • 管理员许可流是指应用程序开发人员将用户定向到管理员许可终结点，意图记录整个租户的许可。 若要确保管理员许可流正常工作，应用程序开发人员必须列出应用程序清单中 RequiredResourceAccess 属性中的所有权限。 有关详细信息，请参阅应用程序清单。

许可提示旨在确保用户有足够的信息来确定他们是否信任客户端应用程序代表他们访问受保护的资源。 了解构建基块将帮助授予许可的用户做出更明智的决策，并帮助开发人员构建更好的用户体验。

下面的图和表提供了有关许可提示构建基块的信息。

许可提示的构建基块

# 组件 目的
1 用户标识符 此标识符表示客户端应用程序正在请求代表其访问受保护资源的用户。
2 标题 标题根据用户是完成用户许可流还是管理员许可流而变化。 在用户同意流中，标题将为“请求的权限”，而在管理员同意流中，标题还有另外一行“代组织接受”。
3 应用徽标 此图像应帮助用户直观地了解此应用是否是他们打算访问的应用。 此图像由应用程序开发人员提供，并且未验证此图像的所有权。
4 应用程序名称 此值应告知用户哪个应用程序正在请求访问其数据。 请注意，此名称由开发人员提供，并且未验证此应用名称的所有权。
5 发布者名称和验证 蓝色的“已验证”标志表示应用发布者已使用 Microsoft 合作伙伴网络帐户验证了其身份，并完成了验证过程。 如果应用已验证发布者，则会显示发布者名称。 如果应用未验证发布者，则会显示“未验证”，而不显示发布者名称。 选择发布者名称会显示更多可用的应用信息，例如发布者名称、发布者域、创建日期、认证详细信息和回复 URL。
6 Microsoft 365 认证 Microsoft 365 认证徽标表示应用已通过来自领先行业标准框架的控制审查，并且制定有强大的安全性和合规性做法来保护客户数据。 有关详细信息，请阅读 Microsoft 365 认证。
7 发布者信息 显示应用程序是否由 Microsoft 发布。
8 权限 此列表包含客户端应用程序请求的权限。 用户应始终评估所请求的权限类型，以了解客户端应用程序获权代表他们（如果他们接受）访问哪些数据。 作为应用程序开发人员，最好是通过最低特权对请求访问权限进行限制。
9 权限说明 此值由公开权限的服务提供。 若要查看权限说明，必须切换权限旁边的 V 形图标。
10 https://myapplications.windowsazure.cn 在此链接中，用户可以查看和删除当前有权访问其数据的任何非 Microsoft 应用程序。
11 在此处报告 如果你不信任该应用，如果你认为该应用正在模拟其他应用，如果你认为该应用会滥用数据，或出于某些其他原因，则此链接可用于报告可疑应用。

以下部分介绍常见方案以及每个方案的预期同意体验。

应用需要一项用户有权授予的权限

在此同意方案中，用户访问的应用需要一个用户授权范围内的权限集。 用户将定向到用户许可流。

管理员会在传统许可提示上看到另外一个控件，从而让其能够代表整个租户进行同意。 该控件默认处于关闭状态，因此只有当管理员显式选中该框时，才能代表整个租户给予同意。 只有角色至少为特权角色管理员角色时，才会显示此复选框，因此云管理员和应用管理员不会看到此复选框。

方案 1a 的许可提示

用户看到的是传统许可提示。

显示传统同意提示的屏幕截图。

应用需要一项用户无权授予的权限

在此同意方案中，用户访问的应用至少需要一项用户授权范围外的权限。

管理员将在传统许可提示上看到另外一个控件，从而让其能够代表整个租户给予同意。

方案 1a 的许可提示

系统将阻止非管理员用户向应用程序给予同意，并将告知用户向其管理员索要对该应用的访问权限。 如果在用户的租户中启用了管理员同意工作流，则用户能够从许可提示提交管理员审批请求。 有关管理员同意工作流的详细信息，请参阅管理员同意工作流。

同意提示的屏幕截图，告知用户向管理员请求对该应用的访问权限

在此同意方案中，用户导航到或定向到管理员同意流。

管理员用户看到的是管理员许可提示。 此提示上的标题和权限说明已更改，这些更改强调了一个事实：接受此提示即表示授予应用代表整个租户访问所请求数据的权限。

方案 3a 的许可提示

将阻止用户向该应用程序给予同意，并将告知用户向其管理员索要对该应用的访问权限。

同意提示的屏幕截图，告知用户向管理员请求对该应用的访问权限

在此方案中，管理员同意应用程序请求的所有权限，这些权限可能包括代表租户中的所有用户的委托权限。 管理员通过在 Microsoft Entra 管理中心进行的应用程序注册的“API 权限”页授予同意。

屏幕截图显示通过 Microsoft Entra 管理中心进行的显式管理员同意。

除非应用程序需要新权限，否则该租户中的所有用户都看不到同意对话框。 若要了解哪些管理员角色可以同意委托的权限，请参阅 Microsoft Entra ID 中的管理员角色权限。

重要

使用 MSAL.js 的单页应用程序 (SPA) 目前要求使用“授予权限”按钮授予显式许可。 否则，在请求访问令牌时应用程序会失败。

常见问题

本部分概述了同意体验的常见问题和可能的故障排除提示。

  • 403 错误

    • 这是委托方案吗？ 用户拥有哪些权限？
    • 是否添加了必要的权限来使用终结点？
    • 检查令牌，看是否具有调用终结点所需的声明。
    • 已同意哪些权限？ 由谁同意的？

  • 用户无法同意

    • 检查租户管理员是否为你的组织禁用了用户同意
    • 确认请求的权限是否为受管理员限制的权限。

  • 即使管理员已同意，用户仍然被阻止

    • 检查静态权限是否已配置为动态请求的权限的超集。
    • 检查应用是否需要用户分配。

排查已知错误

有关故障排除步骤，请参阅针对应用程序执行同意操作时出现意外错误。

另请参阅