SSO 解决了”用户怎么登录”，但没有解决”用户怎么出现在系统里”。一个 500 人的公司，新员工入职第一天就需要访问 15 个 SaaS 工具——IT 部门手动在每个系统里创建账号、配权限，这个过程可能持续到入职后 3-5 天。而当员工离职时，如果 IT 遗漏了任何一个系统的账号注销，登录权限就会在离职后继续存在——这是安全审计的噩梦。

SCIM（System for Cross-domain Identity Management，跨域身份管理系统，RFC 7643/7644）就是为了自动化这件事而设计的。它定义了从企业 IdP 到 SaaS SP 之间账号（User）和群组（Group）的标准化 CRUD 接口。

一、账号生命周期的四个关键时刻

flowchart LR
    A["入职 (JML-Joiner)"] --> B["变岗 (Mover)"]
    B --> C["休假/冻结 (Suspension)"]
    C --> D["离职 (Leaver)"]
    D -.-> A

二、SCIM 2.0 协议核心

SCIM 2.0 定义了两类 HTTP REST 端点：

• /Users：用户资源的 CRUD
• /Groups：群组资源的 CRUD

2.1 User Schema

一个标准的 SCIM User 资源（RFC 7643, Section 4.1）：

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": "2819c223-7f76-453a-919d-413861904646",
  "externalId": "employee-12345",
  "userName": "zhangsan@company.com",
  "name": {
    "familyName": "Zhang",
    "givenName": "San",
    "formatted": "San Zhang"
  },
  "displayName": "San Zhang",
  "emails": [
    {"value": "zhangsan@company.com", "type": "work", "primary": true}
  ],
  "active": true,
  "groups": [
    {"value": "e9e30dba-f08f-4109-8486-d5c6a331660a", "$ref": "/Groups/e9e30dba", "display": "Engineering"}
  ],
  "meta": {
    "resourceType": "User",
    "created": "2026-01-15T08:30:00Z",
    "lastModified": "2026-06-14T10:00:00Z",
    "version": "W\/\"f250dd84f067\"",
    "location": "https://sp.example.com/scim/v2/Users/2819c223"
  }
}

关键字段：

• id：SP 内部生成的唯一标识（不可变）。
• externalId：IdP 侧的标识——通常是 HR 系统的员工号或 AD 的 objectGUID。这是连接 IdP 和 SP 用户的关键桥梁。
• userName：登录名，在 SP 中唯一。
• active：账号是否激活。false 表示禁用但不是删除。
• meta.version：ETag，用于乐观并发控制。
• schemas：指示这个资源顺应哪些 schema——核心 schema + 可选的企业扩展。

2.2 Patch 操作：比 PUT 更关键

SCIM 的 PATCH /Users/{id} 支持三种操作类型（RFC 7644, Section 3.5.2）：

一个典型的”变岗”PATCH 请求：

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "replace",
      "path": "title",
      "value": "Senior Engineer"
    },
    {
      "op": "replace",
      "path": "department",
      "value": "Platform Engineering"
    },
    {
      "op": "add",
      "path": "groups",
      "value": [
        {"value": "groupId-ops", "display": "Operations"}
      ]
    },
    {
      "op": "remove",
      "path": "groups",
      "value": [
        {"value": "groupId-intern", "display": "Interns"}
      ]
    }
  ]
}

工程陷阱 1：replace 操作是属性级别的整体替换，不是 JSON Patch 的”修改某个嵌套字段”。如果你只想改 name.givenName，需要发送 "path": "name.givenName"——SCIM 支持用点号路径访问子属性。如果直接 "path": "name"，会替换整个 name 对象。

2.3 ETag 并发控制

SCIM 使用 ETag（meta.version）做乐观并发控制（RFC 7644, Section 3.13）：

• 读取用户时，返回 meta.version 作为 ETag。
• 更新用户时，客户端在 If-Match Header 中传递当前 ETag。
• SP 检查 ETag 是否匹配，不匹配则返回 409 Conflict。

这防止了多个 IdP 管理员同时修改同一个用户导致的丢失更新。

三、同步模式：Delta Sync 是唯一正确的选择

SCIM 定义了两种数据同步模式：

3.1 Full Sync（全量同步）

IdP 定期拉取 SP 的全部用户列表，与自己侧的数据做 Diff，然后推送变更。问题很明显：一个 10000 人的公司，每次全量拉取传输几 MB 数据，与 100 个 SP 对接，轮询周期导致变更延迟——效率低下。

3.2 Delta Sync（增量同步）

IdP 在每次同步后记住上次同步的时间点，下次只拉取该时间点之后变更过的资源。SCIM 的 GET /Users?filter=meta.lastModified gt "2026-06-14T08:00:00Z" 实现。

工程陷阱 2：SCIM 的 filter 语法（RFC 7644, Section 3.4.2.2）不是 SQL，不要被 filter= 参数名骗了。它只支持有限的操作符：eq、ne、co、sw、ew、pr、gt、ge、lt、le，以及 and/or。不支持嵌套逻辑、不支持 JOIN、不支持 NOT。复杂的筛选逻辑需要 SP 自己扩展或在应用层做二次过滤。

3.3 实际同步节奏

在企业 SCIM 系统中，实际的同步模式是两个层次：

1. 事件驱动 + 批量回退：IdP 在用户变更发生时立即推送 SCIM 请求到 SP（事件驱动），同时保留每日一次的全量对账（批量回退），确保没有遗漏的变更。
2. 限流与重试：SP 的 SCIM 端点应该有速率限制——一个 50000 人的公司可能在某些事件（如组织重组）下触发大量同时的 SCIM 调用。IdP 收到 429 后应退避重试。

Azure AD 的 SCIM 实现要求 SP 实现特定的端点发现路径：

• 用户端点：/scim/v2/Users
• 群组端点：/scim/v2/Groups
• Schema 端点（可选但建议）：/scim/v2/Schemas
• 服务配置端点（可选）：/scim/v2/ServiceProviderConfig

Azure AD 默认每 40 分钟执行一次同步周期。对于紧急变更（如离职注销），管理员可以在 Azure AD Portal 手动触发”Provision on Demand”。

Azure AD 特有的坑： - 默认不推送群组成员关系——需要在 Provisioning 配置中显式启用 “Group Provisioning”。 - 对 DELETE 操作的支持有限——Azure AD 倾向于用 PATCH active: false 软删除，而不是物理删除。

4.2 Okta Provisioning

Okta 的 SCIM 实现支持更灵活的属性映射——管理员可以在 Okta Admin Console 中自定义 Okta 用户属性到 SCIM Schema 属性之间的映射。

Okta 特有的坑： - Okta 的 SCIM 集成模板分为 “SCIM 2.0 Template” 和 “SCIM 1.1 Template”——确认客户用哪个版本。 - Okta 的 import 功能（从 SP 拉取用户到 Okta）通常需要 SP 实现完整的 /Users GET 和分页逻辑。

五、Schema 扩展：企业用户属性

SCIM 2.0 核心 schema 的 User 属性非常基础。RFC 7643 定义了企业用户扩展 schema（urn:ietf:params:scim:schemas:extension:enterprise:2.0:User）：

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User",
    "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
  ],
  "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
    "employeeNumber": "EMP-12345",
    "costCenter": "CC-BJ-ENG",
    "organization": "Platform Engineering",
    "division": "Infrastructure",
    "department": "Security",
    "manager": {
      "value": "26118915-6090-4610-87e4-49d8ca9f808d",
      "$ref": "/Users/26118915",
      "displayName": "Li Si"
    }
  }
}

如果你的 SP 需要特定的业务属性（如”来自中国团队”“有 AWS 管理员角色”），SCIM 允许自定义 schema 扩展，但需要和 IdP 确认对方是否支持把这些属性写入对应的 SCIM 字段。常见的情况是：SP 的自定义 schema 很丰富，但客户的 IdP（尤其是 Azure AD 和 Okta 的默认配置）只填充核心字段——你需要和客户对齐”哪些字段是一定会推送过来的”。

六、小结

SCIM 是 SSO 的”另一半”——SSO 解决”怎么进来”，SCIM 解决”谁能进来”。对于要做企业级 SaaS 的团队：

1. 实现 SCIM 2.0 /Users CRUD + PATCH + filter（至少支持 userName 和 externalId 的 eq 过滤器）。
2. 支持 Delta Sync（基于 meta.lastModified 的过滤）和分页（避免一次返回所有用户）。
3. 与客户对齐属性映射——确认 userName 的来源（email 还是 AD UPN）、externalId 的值（员工号还是 objectGUID）、企业扩展 schema 中哪些字段会推送。
4. 离职注销默认用 active: false 软删除——Azure AD 和 Okta 都倾向这种模式。
5. 做好限流和重试——SCIM 端点也是生产 API，需要和网关层的限流策略协同。

上一篇：SAML 还值得学吗：企业遗留 SSO 的现实世界 下一篇：JWT、JWS、JWE、JWKS 一次讲透