是否缓存了 Azure Active Directory 同意？答案

【问题标题】：Is Azure Active Directory Consent Cached?是否缓存了 Azure Active Directory 同意？
【发布时间】：2017-10-18 04:51:10
【问题描述】：

我们正在构建一个使用 Azure AD 的本机应用程序。该应用程序需要一些权限（例如读取用户配置文件、执行 Azure 服务管理 API 等）。

当用户第一次使用我们的应用程序时，他们会被要求登录，一旦他们登录，他们就会看到同意屏幕（他们同意我们的应用程序）。一旦用户同意，他们就可以在他们的 Azure AD 中看到我们的应用程序（在“应用程序”选项卡下）。到目前为止一切顺利。

现在这个用户所做的是从他们的 Azure AD 中手动删除我们的应用程序（再次通过“应用程序”选项卡）。根据我们对同意模型的理解，这意味着用户已经取消了对我们应用程序的同意。

现在，当该用户登录我们的应用程序时，我们期望用户再次看到同意屏幕（如第一次）。然而，实际行为是用户没有看到这样的屏幕，用户只是登录到我们的应用程序。此外，当用户返回其 Azure AD 时，他们不会在许可应用列表中看到我们的应用程序。

所以我的问题是：

任何关于为什么会发生这种情况的见解都将受到高度赞赏。

【问题讨论】：

通过图中的一组 oauth2PermissionGrant 对象授予同意，这些对象将 oauth2Permission（在应用程序上定义）连接到客户目录中的服务主体，当然还有用户 ID同意已完成（或全部同意，如果已完成管理员同意）。您可以使用图形资源管理器检查这些授权是否存在，并查看用户删除应用后它们会发生什么。
关于使用图形浏览器检查同意的好建议。谢谢！将做同样的事情并相应地更新问题。

【解决方案1】：

在 Azure Active Directory 中，用户同意注册为用户对象和代表客户端应用程序的服务主体对象之间的链接。

此链接在 AAD Graph API 中表示为 OAuth2PermissionGrant

你是这么说的：

现在这个用户所做的是手动从他们的应用程序中删除我们的应用程序 Azure AD（再次通过“应用程序”选项卡）。基于我们的对同意模型的理解，这意味着用户已删除对我们申请的同意。

我想澄清一下。您可能知道，当您创建新的 AAD 应用程序时，您需要牢记Application Object and a Service Principal 之间的区别。

特别是，如果您删除代表客户端应用程序的服务主体，则连接到该服务主体的所有同意链接都将被销毁，从而有效地删除同意。如果您只删除应用程序对象，则不能这样说，这很可能是您遇到问题的地方。

我解释了here 撤销 Azure Active Directory 应用程序许可所需的最简单步骤。让我知道这是否有帮助。

【讨论】：

谢谢肖恩。使用您博客文章中提到的My Apps 门户，我们能够解决这个问题。仍然存在一个问题 - 管理员如何删除对单个用户的应用程序的同意？
您能解释一下您想要执行此操作的场景吗？代表另一个用户这样做没有任何意义。
只是大声思考 - 仍然是 Azure AD 的一部分但不再需要访问第 3 方应用程序的用户（假设用户转移到组织中的不同团队）。这种场景有意义吗？
假设您取消了他们的同意...他们可以再次同意。如果您想限制用户对应用程序的访问权限，您将需要设置应用程序角色或类似的东西，但您的方案并没有真正阻止用户做任何事情。话虽如此，假设用户单独同意该应用程序，那么您作为管理员可以删除代表该应用程序的 oauth2permissiongrant。