SaaS项目身份管理选型：Azure B2C与B2B场景适配咨询

先把两个产品的适用边界说清楚，你之前混淆的预配置功能归属直接给结论：

• 你查到的Azure AD用户预配置能力属于标准Azure AD（B2B依托的企业版AAD），不属于B2C的功能范畴，这个功能的设计目标是企业内部IT管理员把自己公司AAD租户里的员工账号同步到第三方SaaS，根本不是给SaaS厂商用来做自己平台上多客户的用户管理用的。
• B2B的核心定位是「你作为SaaS服务商，在自己公司的AAD租户里邀请外部合作方访问你自己企业的内部资源」，所有外部访客账号都存在你自己的AAD租户下，没有给你平台上的每个客户企业做独立租户隔离的原生能力，也不支持陌生用户的公开自助注册——你要让任意访问网站的用户能自己注册创建企业，B2B从根上就不支持。
• B2C是微软专门给面向外部客户的应用、多租户SaaS做的身份管理服务，不绑定你自己企业的AAD租户边界，原生支持公开自助注册、自定义用户属性、自定义注册登录流程，完全适配你的基础场景。

别硬蹭AAD原生的权利管理、跨租户同步那些功能，那些都是给企业内部IT场景做的，套到你的多租户SaaS场景里只会把架构搞复杂，按三层做就行，维护成本最低：

1. B2C基础配置 #

• 配两个独立的用户流：
  • 公开注册登录流：开放给首次访问的用户，完成注册后自动在业务库创建对应的企业主体，给这个用户标记为对应企业的admin角色，同时把企业ID、角色值写入B2C用户的扩展属性
  • 邀请专用注册流：关闭公开访问入口，仅通过带参数的邀请链接触发
• 在B2C里给用户schema加两个扩展字段：tenant_id（关联用户所属的平台企业ID）、role（存储admin/editor/dev三个角色值），配置成ID令牌的签发声明，用户登录后应用直接从token里就能拿到这两个值，不用每次请求都查身份库。

2. 邀请流程逻辑 #

• 企业admin在后台发起邀请时，业务侧生成一个72小时有效的带签名邀请令牌，令牌里存目标企业ID、预分配的被邀请人角色、受邀人邮箱，拼成专属邀请链接发给对方。
• 受邀人点击链接跳转到B2C的邀请注册流时，把邀请令牌作为上下文参数传给B2C自定义策略，策略里先做令牌合法性校验：验签、判断是否过期、受邀邮箱是否匹配，校验通过才允许进入注册步骤。
• 用户完成注册（支持本地账号密码、微软/谷歌等社交账号、后续大客户还可以直接对接对方企业的自有身份源）后，B2C自动把令牌里带的tenant_id和role写入对应用户的扩展属性，全程不需要额外做用户数据同步。

3. 权限校验逻辑 #

• 应用侧拿到B2C签发的token后，先做两层校验：第一层校验token里的tenant_id和当前访问的资源所属企业ID一致，杜绝跨租户越权；第二层校验role是否匹配当前接口/页面的访问权限：
  • admin：可访问用户管理模块，发起邀请、调整同企业下用户的角色
  • editor：仅可访问内容管理相关功能
  • dev：仅可访问API密钥、集成配置相关功能
• 后续如果有大客户需要把自己公司的内部账号全量同步到平台，不用改整体架构，只要在B2C里给对应企业配置专属身份联合，再加个标准SCIM接口对接客户的身份系统就行，扩展性足够。

别尝试用B2B做这个场景，我之前踩过坑：当时为了省事儿用B2B做中小客户SaaS的身份，结果所有客户的访客账号都堆在我们自己的AAD租户里，不仅自助注册要自己写一整套接口绕B2B的限制，后期做租户隔离的时候踩了无数权限泄漏的坑，最后还是全量迁移到B2C才解决。

内容的提问来源于stack exchange，提问作者Wile E. Coyote