TL;DR
当通常的 interactive 方式（例如带有同意屏幕弹出窗口的 Web 应用程序）不可行时，如何将我的用户权限委派给 Azure Ad 中的服务主体？这是因为我无法在 Azure 门户中正确配置 MSI 以使其正常工作。
更多细节
我想授予应用程序权限以代表用户访问图形 API。通常，这是一个 well-documented 场景，您在其中创建应用注册，通过请求所需范围的权限来获取 delegated user permissions，然后在应用中使用这些权限。
需要 Graph 访问权限的应用程序是一种后台服务，可以在没有用户干预/活动的情况下自行运行。对于此用例，常用方法是使用 application permissions。在我的情况下，这是不可行的，因为应用程序权限需要管理员同意并且是全有或全无的权限。这不会授予我。理所当然，因为它太过分了。
但另一方面，这真的很遗憾。很遗憾，因为我找到了关于如何将 Graph API 应用程序权限直接分配给 Managed Service Identity 而不是自注册应用程序的 example。我的服务（作为 Azure Functions 应用程序）已经分配了一个 MSI。所以这将是完美的选择，b 再说一次，我无法获得这些应用程序权限。
那么解决方法是什么？我们有这个user principal，它具有我们后台服务所需的所有必需权限。我想做的是将此用户的权限委托给Function App/MSI。为了做到这一点，我使用了 this SPA-template by the MSAL team 来提示我弹出权限。
但是这失败了，因为 implicit oauth flow 没有被启用。要解决此问题，您通常需要更新门户中的应用程序清单。但是，由于这是一个 MANAGED 服务身份，而不是自我注册的身份，因此 MSI 未列在应用程序注册下的门户中。所以我不能将此属性设置为 true。
通过 Azure CLI 执行相同操作也失败了，因为显然 MSI 未被识别为应用程序。
az ad app update --oauth2-allow-implicit-flow true --id <appId_of_MSI>
这会产生以下错误：
ResourceNotFoundError: Resource '<appId_of_MSI>' does not exist or one of its queried reference-property objects are not present.
这样做时显示正常
az ad sp show --id <appId_of_MSI>
总而言之：我无法完成委派该用户的权限 interactively 的过程。有没有其他办法？也许通过 CLI？
该解决方案的后备方案是创建一个单独的非托管/自注册应用身份。但我真的想避免这种情况，因为那样我将需要再次管理和轮换客户端（应用程序）凭据，而 MSI 会为我处理这些。
为什么我不能只分配细范围的应用程序权限?
非常感谢您对此的任何帮助。干杯。
答案 0 :(得分：1)
根据我的经验，托管身份不支持您建议的方案。 他们没有应用注册，因此无法以交互方式验证用户。
我会采用您的后备解决方案；一个普通的应用程序注册并使用它来代表用户访问 Graph API。 这至少是我们在项目中所做的。 应用权限 -> 如果可能的话，管理身份。委派权限 -> 普通应用注册 + Key Vault 中的机密/证书，使用托管标识检索。