【身份与访问控制工程】CIAM 架构：面向 B2B / B2C SaaS 的身份平台

前 17 篇文章讨论的 IAM 机制（OIDC、SAML、MFA、权限模型、令牌管理）是”通用组件”——既适用于员工身份管理（Workforce IAM），也适用于客户身份管理（CIAM，Customer IAM）。但当这些组件被放在”面向外部客户”的场景中，架构的优先顺序完全变了。

本文聚焦 CIAM 与 Workforce IAM 架构的五个本质差异。

一、CIAM vs Workforce IAM：五个本质差异

CIAM 的核心张力不是技术性的——它是”用户体验（转化率）“和”安全”之间的持续平衡。Workforce IAM 的默认立场是”不信任”（MFA 强制、Session 有效期短），而 CIAM 的默认立场是”信任直到有理由怀疑”（减少摩擦、允许社交登录、延长会话有效期）。

二、注册漏斗与渐进式画像

CIAM 的注册不是”HR 录入员工信息”——它是一个转化漏斗，每一步都会丢失用户。

触达 Landing Page
  → 点击注册 (留存 30%)
    → 填写注册表单 (留存 50%)
      → 邮箱验证 (留存 80%——但 20% 用户不查邮箱)
        → 首次登录 = 总留存约 12%

减少流失的工程策略：

1. 社交登录（Social Login）：点击”用 Google 登录”省略整个注册表单。转化率提升 20-50%。
2. 渐进式画像（Progressive Profiling）：注册时只问三件事（邮箱、密码、名字），其余信息（公司、角色、使用场景）在后续使用中逐步收集——每次只问一个问题，在自然流转中出现。
3. 延迟验证：注册后立即进入应用（有基础功能），在后台发送验证邮件。用户不用等待邮件就能开始使用。在执行关键操作（如付款、创建团队）时强制验证邮箱。

2.1 防止注册滥用

开放的注册端点容易被滥用——机器人注册、一次性邮箱注册、撞库。防御策略：

• CAPTCHA / Turnstile：Cloudflare Turnstile（不可见 CAPTCHA）对转化率的影响远小于传统 reCAPTCHA（需要点击”我不是机器人”）。
• 一次性邮箱域名黑名单：维护已知的一次性邮箱域名列表（如 mailinator.com、guerrillamail.com），在注册时拒收。
• 速率限制：同一 IP 每 15 分钟最多注册 3 个账号。
• 邮箱格式启发式：检测随机字符串 + 已知邮箱域名（如 a1b2c3d4@gmail.com），要求额外验证。

三、同意管理（Consent Management）

CIAM 的合规性需求（GDPR、CCPA、中国的《个人信息保护法》）比 Workforce IAM 高一个数量级，因为”客户数据”和”员工数据”在法规上的保护级别不同。

CIAM 的同意管理系统需要追踪：

CREATE TABLE user_consents (
    user_id        UUID NOT NULL,
    consent_type   VARCHAR(64) NOT NULL,   -- 'marketing_email', 'data_processing', 'third_party_sharing'
    consented      BOOLEAN NOT NULL,       -- true = opt-in, false = opt-out
    consent_source VARCHAR(128),           -- 'registration_form', 'preference_center', 'api'
    ip_address     INET,
    user_agent     TEXT,
    consented_at   TIMESTAMP NOT NULL,
    revoked_at     TIMESTAMP,              -- NULL = still active
    consent_version VARCHAR(32) NOT NULL,  -- 同意条款的版本号
    PRIMARY KEY (user_id, consent_type, consent_version)
);

关键设计点：

• 版本化：当隐私政策或使用条款更新时，旧版本的同意不一定仍然有效。某些法规要求用户重新同意。
• 不可否认性：需要保存完整的同意记录——包括时间戳、IP、当时的条款版本和内容快照——以应对审计和用户投诉。
• 数据删除权：用户请求删除数据时，大多数数据必须被物理删除，但同意记录可能需要保留（作为”他们当时同意了”的法律证据）。这需要事前在数据分类中标识”不可删除的合规记录”。

工程陷阱：很多团队把同意记录存在 Elasticsearch 的日志里，然后日志设了 90 天 TTL——当监管机构 2 年后要求提供证据时，同意记录早已被清理。同意记录需要存储在不可轮转的持久存储中（如 S3 的合规存储桶、专门的审计数据库表）。

四、B2B + B2C 混合架构

许多 SaaS 平台同时有 B2C 用户（个人消费者）和 B2B 用户（企业客户）。第一种方案是两套独立的 CIAM 实例——B2C 和 B2B 的用户基础是分离的。第二种方案是统一身份平台——同一套 CIAM 同时服务 B2C 和 B2B，用户可能在 B2C 注册后升级到 B2B（通过加入组织或购买企业方案）。

混合架构的挑战在于授权模型的差异：

• B2C 用户：自注册，个人资料，个人订阅，没有组织。
• B2B 用户：通过 SSO 或组织邀请加入，属于一个组织，权限由组织管理员管理。

在统一平台中，User 表需要支持两种身份来源：

CREATE TABLE users (
    id              UUID PRIMARY KEY,
    email           VARCHAR(255) UNIQUE,
    identity_source VARCHAR(32),  -- 'self_registered', 'sso', 'invited', 'admin_created'
    tenant_id       UUID,         -- NULL for B2C, NOT NULL for B2B
    -- ...
);

权限检查需要区分： - 如果 tenant_id IS NULL → 用户是 B2C 用户，权限由平台默认 RBAC 决定。 - 如果 tenant_id IS NOT NULL → 用户是 B2B 用户，权限由该租户的角色 + 组织树决定。

五、小结

CIAM 工程的核心不是新协议或新技术，而是新优先级：

1. 转化率是 KPI——每个额外的注册字段在流失用户，每个额外的认证步骤也在流失用户。
2. 合规不是可选的附加模块——GDPR/CCPA/个保法的数据删除权、数据可携带权、同意撤回权必须从第 1 天就内建在数据模型中。
3. 同意记录是合规证据——不可轮转，不可丢失——存储在持久化的审计存储中。
4. B2B/B2C 混合不是两套代码——是一套统一身份平台，通过 tenant_id 和权限模型区分行为。

上一篇：自建还是采购：Keycloak、Auth0、Entra、Okta 对比 下一篇：PAM、IGA 与审计合规