员工身份与客户身份：企业身份管理的分水岭

在企业软件架构中，“身份”往往被当作一个统一概念来处理，直到登录失败、权限错配或离职账号未回收等问题出现，团队才意识到：员工身份（Workforce Identity）与客户身份（Customer Identity）本质上是两套逻辑。理解它们的差异与连接点，是B2B软件设计身份体系的第一步。

核心差异：控制边界与生命周期

员工身份面向内部组织，由IT或安全团队集中管理。账号的创建与注销通常与HR系统联动，生命周期相对确定：入职开通、转岗调整、离职回收。其核心诉求是安全与合规——谁能访问哪些内部系统，必须可审计、可追溯。

客户身份面向外部用户，由产品与增长团队主导。用户自行注册、自助登录，规模可能从几百到数百万不等。其核心诉求是转化与体验——注册流程每多一步，流失率就可能上升。客户身份的生命周期不由企业单方面决定，用户可能长期沉默，也可能随时回归。

这两套逻辑决定了技术选型的差异：员工身份倾向集成企业目录（如SSO、SCIM），客户身份则需要支持社交登录、多因素认证与高并发下的弹性扩展。

SSO（单点登录） 是一种认证机制，允许用户使用一组凭据登录多个相互信任的应用系统，而无需重复输入密码。在企业身份场景中，SSO 通常由身份提供商（IdP）实现，如 Okta、Azure AD，员工登录一次即可访问所有授权应用，既提升体验又集中管控安全策略。

SCIM（跨域身份管理系统） 是一种开放标准协议，用于在身份提供商与业务应用之间自动同步用户和组信息。它解决了员工入职、转岗、离职时账号手动创建与回收的痛点，通过标准化 API 实现用户生命周期的自动化管理，是员工身份与 HR 系统联动的关键技术。

SSO 解决“认证”问题，SCIM 解决“账户管理”问题，两者常配合使用，构成企业身份管理的基础设施。

B2B软件中的交汇点

在B2B产品中，两类身份并非完全隔离。典型场景是：企业客户购买SaaS产品后，其员工以“客户侧用户”的身份登录，但权限模型又需要映射到该企业内部的角色结构。此时，产品既要处理终端用户的注册体验，又要满足企业管理员对成员权限的集中管控。

交汇带来的复杂度在于归属边界。一个用户可能同时属于多个企业租户，权限随租户切换而变化；企业管理员需要能够邀请、停用成员，但不应触碰平台级的安全策略。清晰划分“平台管什么、租户管什么、用户自己管什么”，是B2B身份设计的核心挑战。

多租户（Multi-tenancy） 是 B2B 软件的核心架构模式，指单一软件实例为多个客户组织（租户）提供服务，各租户的数据与配置逻辑隔离。在身份体系中，多租户意味着同一个用户可能隶属于多个租户，其角色和权限需按租户上下文动态判定。

RBAC（基于角色的访问控制） 通过将权限赋予角色、再将角色分配给用户来简化授权管理，适合企业内相对稳定的职责划分。ABAC（基于属性的访问控制） 则依据用户、资源、环境等多维属性动态决策，灵活性更高，适合复杂或细粒度的场景。平台通常提供这些能力作为基础，租户管理员在此基础上执行具体分配。

谁拥有登录、会员、权限与回收

原文提出的关键问题是团队归属：登录、会员资格、权限分配与访问回收，分别由谁负责。实践中常见的分工是——

• 登录：客户身份团队负责认证流程与用户体验，安全团队制定策略基线；
• 会员：产品团队定义会员等级与权益，与计费系统对接；
• 权限：平台提供RBAC/ABAC能力，租户管理员执行具体分配；
• 访问回收：员工侧由IT通过目录同步自动完成，客户侧则依赖产品内的生命周期规则与风控机制。

模糊地带往往出现在“企业客户的管理员操作”上：这既像内部IT管理，又发生在客户产品界面中。明确由产品团队提供管理能力、由企业客户承担管理责任，可以避免责任真空。

身份提供商（IdP） 是负责创建、维护和管理身份信息，并提供认证服务的系统或服务。在企业环境中，IdP 通常是 Azure AD、Okta 等，员工凭据集中存储于此；在客户身份场景中，IdP 可能是 Auth0、 Cognito 等云服务，或自建认证中心。

明确 IdP 的归属是身份设计的关键决策：员工身份通常复用企业现有 IdP 以实现 SSO，客户身份则往往需要独立的 IdP 以支持社交登录、自助注册等外部用户特性。B2B 产品可能需要同时对接企业 IdP（用于员工登录）和自有 IdP（用于终端用户），并在两者之间建立信任与映射关系。

设计启示

将两类身份强行统一到一套系统，短期看减少了组件，长期却会带来策略冲突：内部安全要求与外部体验优化经常互相拉扯。更务实的做法是共享底层身份基础设施（如令牌服务、审计日志），但在策略层与生命周期管理层保持分离。

身份不是单纯的登录框问题，而是组织边界在软件中的投影。想清楚“谁的人、谁负责、谁回收”，比选型哪个身份提供商更重要。