.NET Core MVC多组织应用多身份验证提供程序及多Azure AD租户实现咨询

这是Azure AD原生支持的能力，完全不需要为每个合作机构单独拆分应用：

• 只需要在首个注册的应用入口把Azure AD应用配置设为多租户模式，即可接收来自任意已开通合作的Azure AD租户的合法认证请求
• 你设想的双登录按钮方案完全可落地：每个按钮直接指向对应合作机构专属的OAuth2授权端点，用户点击机构X的按钮就跳转X的Azure AD登录页，点击机构Y的按钮就跳转Y的登录页，认证完成后统一回跳应用的全局回调地址即可
• 实现时注意在.NET Core的OpenID Connect令牌校验环节，增加租户ID白名单逻辑，只放行约定好的几个合作机构的租户，避免任意第三方Azure AD的用户都能尝试发起登录请求，依托微软官方的Microsoft.Identity.Web组件即可快速完成校验逻辑编写，不需要从零手写认证中间件

要不要引入Azure AD B2C，完全取决于承包商的账号归属场景：

• 如果所有外部承包商的账号，本身就归属在对应合作机构的Azure AD体系内（比如机构X在自己的Azure AD中给承包商开通了域账号、或用Azure AD B2B能力邀请承包商成为本租户的协作嘉宾），那完全不需要引入Azure AD B2C，直接复用前面的多租户Azure AD认证能力，在应用侧根据用户携带的租户ID、用户组声明做权限拦截即可，这是成本最低的实现路径
• 只有当承包商不属于任意合作机构的Azure AD账号体系时，Azure AD B2C才是合适的选择：比如承包商是零散第三方、没有被任何合作机构邀请为Azure AD嘉宾、需要统一配置跨所有机构的自定义登录规则（比如全量MFA、品牌化登录页、自助密码重置），这时候B2C可以直接把多个合作的企业Azure AD配置为联合身份源，同时叠加零散外部账号的认证能力，一套流程覆盖所有用户类型
• 避坑提示：不要为了少量外部承包商无差别引入B2C架构，会额外增加身份体系的运维复杂度，能用现有Azure AD B2B协作能力覆盖的场景，优先选现有方案

每个机构单独部署一套独立应用的模式，本质是单租户应用的物理隔离方案，优劣势非常明确：

• 优势：用户数据、业务数据完全物理隔离，能满足对合规隔离要求极高的机构的审计需求；不需要处理多租户场景下的跨租户权限边界、数据隔离逻辑；单个机构的版本升级、配置调整不会影响其他机构的正常使用
• 劣势：长期运维成本极高——版本迭代、安全补丁、功能上线需要给每个独立部署的实例分别推送，随着合作机构数量增加，运维成本会线性上涨；没有统一的跨机构运维管控视角，排障效率低
• 适用边界：只有当合作机构明确提出强制的物理隔离要求，且愿意承担独立部署带来的额外成本时，才适合选择这个方案；如果没有这类强合规约束，优先选择单多租户应用的方案，长期投入产出比更高

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