代表 MSA(Microsoft 个人)和 AAD 帐户的 Azure Ad v2.0 端点 [英] On-behalf-of on Azure Ad v2.0 endpoint for both MSA (Microsoft personal) and AAD accounts

问题描述

我们有一个面向用户的 Web 应用程序和一个中间层 ASP.NET Core Web api，目前在 Azure Ad v1.0 端点上使用 OAuth 2.0 代表流 (OBO)，仅对 AAD 帐户进行身份验证.我们还需要对 MSA(个人)帐户进行身份验证，因此将我们的解决方案迁移到 Azure AD v2.0 端点.

We have a user-facing web app and a middle-tier ASP.NET Core Web api, currently using OAuth 2.0 On-Behalf-Of flow (OBO) on the Azure Ad v1.0 endpoint, authenticating only AAD accounts. We need to authenticate also MSA (personal) accounts, therefore migrate our solution to the Azure AD v2.0 endpoint.

官方样本 仅验证 AAD 帐户并说:

The official sample only authenticates AAD accounts and says:

"当前限制:代表流程目前不适用于 Microsoft 个人帐户."

"Current limitations: The on-behalf-of flow does not currently work for Microsoft Personal accounts."

有人可以确认一下吗?在这种情况下，为 Microsoft 个人帐户和工作或学校帐户获取服务到服务令牌的替代方法是什么?

Can somebody confirm this ? What is the alternative for getting a service to service token for both Microsoft Personal accounts and work or school accounts if this is the case?

推荐答案

正如文档所说，通用 OBO 模式不能用于同时登录个人和工作或学校帐户的客户.一般准则建议，如果可能，将中间层应用程序和前端 UI 合并为一个 AAD v2.0 应用程序.当然，这只能在您将单个前端映射到中间层时才能完成，并且不适用于多个前端共享同一中间层的情况.

As the documentation says, a common OBO pattern cannot be used for clients that sign in both personal and work or school accounts. The general guidelines recommend, if possible, to merge the middle tier application and the front-end UI into one AAD v2.0 application. Ofcourse, this can only be done if you have a single front-end mapped to the middle tier and won't be applicable in cases of multiple front-ends sharing the same middle tier.

这个link 提供了有关这些限制的原因以及我在上面描述的解决方法的信息.不幸的是，合并这两个应用程序是唯一的方法.

This link provides information regarding the reasons for these limitations and the workaround that I described above. Unfortunately, merging the two applications is the only way.

这篇关于代表 MSA(Microsoft 个人)和 AAD 帐户的 Azure Ad v2.0 端点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！