ASP.NET Core MVC订阅应用是否需使用Azure AD B2C及Graph API？

首先明确一点：Azure AD B2C不会自动帮你完成和业务绑定的自定义群组、角色管理——它的核心是提供身份验证能力，而你需要的用户自主创建群组、邀请成员、分配业务角色这类操作，要么通过Microsoft Graph API编码实现，要么在自己的EF数据库里维护业务逻辑。下面结合你的ASP.NET Core MVC订阅服务场景详细拆解：

1. 先搞懂Azure AD B2C的基础边界 #

• Azure AD B2C单租户完全能满足你的用户身份管理需求：用户注册、登录、身份验证这些基础操作，它可以直接搞定，不用你从零写登录逻辑。
• 它自带的"角色"是Azure平台级的管理员角色（比如全局管理员、用户管理员），这些和你业务里的"订阅群组管理员""普通成员"不是一回事，没法直接复用。
• 它支持用户组，但默认的组管理是平台层面的——如果你只是需要把用户归到某个组来控制Azure资源权限，那可以直接用，但如果要把组和你的订阅服务数据、业务权限绑定（比如某个群组只能访问自己的订阅数据），就需要你自己对接逻辑。

2. 什么时候必须用Microsoft Graph API？ #

当你需要实现动态业务级群组/角色操作时，Graph API是核心工具：

• 用户创建自定义群组：在你的应用界面点击"创建群组"后，后端需要调用POST /groups接口创建Azure AD组，同时把组信息和你的订阅业务数据关联（比如存在EF数据库里）。
• 邀请用户加入群组：调用POST /groups/{groupId}/members/$ref接口，把被邀请用户的Azure AD用户ID添加到组里；如果是邀请未注册的用户，还可以用B2C的邀请功能结合Graph API发送邀请链接。
• 分配业务角色：如果你的角色是动态的（比如每个群组可以自定义角色），建议把角色存在自己的EF数据库，和用户、群组关联；如果是固定角色（比如管理员/普通成员），可以用Azure AD的应用角色（App Roles），在Azure门户预定义后，用户登录时会携带角色声明，你可以在ASP.NET Core里通过声明判断权限，这种情况不需要手动调用Graph API管理角色，但群组的动态操作还是需要。

3. 替代方案：完全自主维护业务逻辑 #

如果你不想依赖Graph API，也可以把群组、角色、成员关系完全存在自己的EF数据库里：

• Azure AD只负责用户身份验证，登录后你从自己的数据库里获取用户所属的群组、角色信息。
• 这种方式更灵活，能完全自定义业务规则（比如群组的订阅权限、角色的具体权限），不用受Azure AD组的限制，但缺点是失去了Azure AD组的一些原生特性（比如组级别的身份验证声明、同步到其他Azure服务）。

4. 针对你的订阅服务场景的最终建议 #

• 优先选择Azure AD B2C单租户 + Graph API管理群组 + EF数据库维护业务角色/订阅关联的组合：既利用了B2C的身份验证能力，又能实现用户自主创建群组、邀请成员的动态需求，同时通过EF数据库绑定订阅业务逻辑。
• 如果你的角色是固定的，用Azure AD应用角色来简化权限判断；如果角色需要随订阅套餐或用户自定义变化，就自己在EF里维护角色数据。

内容的提问来源于stack exchange，提问作者Ian Gleeson