我们的产品是CASB（Cloud Access Security Brooker）。因此，我们的客户正在授予我们的O365应用程序几乎所有权限，以便我们可以帮助他们监控和保护他们在云中的数据，用户和声誉。
作为此产品的一部分，我们提供有关针对其O365实例安装了哪些第三方应用程序的信息，甚至可以根据这些应用程序的功能，可访问的资源甚至是其声誉来计算这些应用程序的风险评分。的供应商。
我们在仪表板/管理控制台中向客户展示所有这些信息，以便他们更加了解用户在O365租户中安装/启用的内容。但是，我们也希望让他们能够修复这些应用程序。修复有两种形式，手动修复和基于规则/策略的修复。
因为我们的应用程序设计为在幕后运行而不需要已登录的用户，所以我们一直使用应用程序权限调用Microsoft Graph API。但是，当我们尝试实现应用程序的修复时，我们发现应用程序权限不支持对ServicePrincipals的DELETE HTTP调用，而只是通过委派权限。我们发现OAuth2PermissionGrants和AppRoleAssignments也是如此，如果我们要修复单个用户的访问而不是整个应用程序，我们也希望这样做。
我们的应用程序流使用委派权限并不实际，因为我们没有登录用户，但设计为在后台运行。
如果我们的客户愿意在安装时向我们的产品授予此访问权限，为什么不通过应用程序权限将其提供？强制这些调用使用已签名的用户模型似乎是一个奇怪的决定，它可以控制O365租户的所有者。
我相信像我们这样的其他安全产品在为客户管理O365第三方应用程序方面也会有类似的需求。