为什么不是？

下面我从架构、规模、演进、团队、生态、安全、性能、合规等维度，系统性回答：

为什么企业级 IAM 不应该做成 all-in-one，而必须拆成多个子系统。

我会结合你目前已有的模块（UMS、Permission、SSO、Passport）给出专业级论证。

1. 单体 all-in-one 的核心问题：边界违背职责单一原则

IAM 不是单一能力，而是至少包含 6 大独立能力：

  • 身份（User Identity）
  • 凭证（Credentials）
  • 会话 & Token（Session/Token Service）
  • 认证（Authentication / MFA / SSO）
  • 授权（Authorization）
  • 应用生态（App / Client Management）
  • 审计 & 安全 & 风控（Audit/Risk）

这些能力来自完全不同的安全域（Security Domains）。 把它们塞进一个系统，会导致：

  • 模块间强耦合，难以隔离边界
  • 一个模块的变更影响所有模块
  • 无法独立扩展能力（例如你要升级 MFA，会影响 Permission？）
  • 不同安全域的责任交叉，产生安全隐患（权限服务能读用户密码？）

安全系统第一原则： 能力边界必须清晰，不可以混写。

2. 单体无法满足企业级 IAM 的扩展性需求

IAM 是全企业入口，未来必然需要：

  • 支持成百上千个业务系统
  • 对接 SAML、OIDC、OAuth2、企业 AD、LDAP
  • 大规模的用户（10w+）
  • 每秒数千次 Token 校验
  • 高频鉴权（每个 API 都要鉴权）

如果你 all-in-one，EVERYTHING 都耦合到一个进程：

  • 认证压力来了？整个系统扩容
  • 权限校验压力来了？整个系统扩容
  • 业务系统调用变多？整个 IAM 整体要扩容
  • 日志写入激增？整个 IAM 变慢

拆分后：

  • SSO 单独扩容
  • Token Service 单独扩容
  • Permission 单独扩容
  • Audit 单独部署到大吞吐架构（ELK/ClickHouse）

扩展成本完全不同。

3. 安全架构必须分域（Zero Trust 原则）

安全系统不能 all-in-one 的最核心原因：

权限服务不能访问密码，认证服务不能读取策略，审计日志不能干预授权。

举几个实际安全风险：

  • 如果 Permission 系统能读取用户凭证（密码、MFA）→ 严重合规违规
  • 如果 UMS 和 Permission 在同一进程内 → 任意命令执行漏洞影响两者
  • Token 服务与权限服务耦合 → 一处越权漏洞即可伪造 Token
  • 审计与业务耦合 → 攻击者删除日志会写入攻击痕迹

企业级 IAM（Okta、Auth0、AzureAD、AWS IAM）全部都是严格系统分域。

4. 单体无法支持多团队并行开发

IAM 是跨公司级别的系统，要支持的场景非常多，包括：

  • 业务应用团队
  • 安全团队
  • 运维团队
  • 企业架构师
  • 审计与合规团队
  • 外部系统对接团队

单体 → 所有人压到一个仓库，任何人改代码都会影响整个 IAM 拆分 → 每个域独立

  • UMS（用户管理）由架构/用户团队维护
  • Permission（授权）由安全团队维护
  • App Manager 由平台团队维护
  • 审计由运维/安全团队维护
  • Token Service 由基础架构团队维护
  • SSO/Passport 由认证团队维护

可独立迭代、独立 API、独立 SLA。

5. 单体开发会使架构恶化（IAM 会变成垃圾桶系统）

现实中的反模式：

摆在一起的系统（用户、权限、认证）→ 很多人把各种逻辑塞进去。

你会逐步看到：

  • 密码规则、用户资料、登陆 UI、组织架构、权限管理、菜单管理、应用管理、审计日志、风险策略、第三方登录策略 全部混写在一个项目里。

最后 IAM 成了一个超级大杂烩，任何更新都风险巨大。

拆分是为了：

  • 强制性边界
  • 强制模块职责明确
  • 防止系统“随便加东西”变得肿胀不可维护

6. 单体在高吞吐鉴权场景直接崩溃

企业 IAM 最典型的场景：

  • API Gateway 每秒几十万次鉴权
  • 每次都要问 Permission：此用户是否可访问此资源？
  • 每次都要问 Token Service：Token 是否有效？是否过期？

all-in-one 会产生：

  • 认证流程阻塞鉴权流程
  • 权限查询阻塞 Token 校验
  • 审计写入阻塞 SSO 登录
  • 第三方登录阻塞用户管理

拆分后：

  • Token 校验走 Redis 或本地缓存 → 毫秒级并发
  • Permission 的策略引擎可以水平扩展
  • SSO 登录不会影响业务调用
  • Audit 写入异步，不影响主链路

性能直接提升几十倍。

7. 单体无法支持企业 IAM 的生态化能力

企业 IAM 是一个生态平台，而不是单应用。

你未来会有：

  • 应用商店
  • 应用下发
  • 应用授权
  • SSO 集成
  • 业务系统自动登录
  • 第三方系统接入
  • 外部 OIDC/SAML 集成
  • SCIM 自动化用户同步
  • 组织架构同步
  • API 权限网关

这些独立能力在一套 all-in-one 中维护，会导致：

  • 业务越来越复杂
  • 模块相互影响
  • 重构成本极高
  • 生态系统难以扩展

拆分后，每个子系统都是一个产品组件，可以独立对外提供 SDK 或 API。

8. 单体不符合现代 IAM（Identity Fabric）的架构理念

国际上对 IAM 的标准架构叫做：

Identity Fabric（身份织网）

核心原则：

  • 小而专、解耦、可替换
  • 每个能力可独立部署、扩展、自治
  • 模块通过标准协议联通（OIDC、OAuth2、SCIM）

all-in-one 会直接违背 Identity Fabric 的原则。

9. 单体对合规性来说不可能通过审计

例如：

  • SOX
  • ISO 27001
  • GDPR
  • 金融合规（PCI DSS）
  • 国企审计（等保）

所有合规要求：

  • 权限不可越权访问密码
  • 密码管理必须与授权分离
  • Token 必须可单独审计、隔离
  • 审计日志必须不可被业务修改
  • 身份源必须独立于授权模块

all-in-one 无法满足合规。

10. 那为什么小公司都做 all-in-one？

因为他们没有 IAM，他们做的是一个：

  • 小型 RBAC
  • 简易登录系统
  • 简单用户管理
  • 一体化管理后台

而你要做的是：

企业级 IAM 平台（类似于 Okta + AzureAD + Auth0 的组合）

这是完全不同的复杂度。

结论（核心）

企业级 IAM 系统 必须拆分为多个子系统，原因包括：

  • 安全域必须隔离
  • 模块职责必须清晰
  • 扩展性与性能需求巨大
  • 支持全企业生态化接入
  • 满足合规与审计要求
  • 支撑大规模 Token/权限鉴权
  • 支持多团队并行开发
  • 防止架构长期恶化

all-in-one 只能满足公司的登录页面需求，但无法支撑企业级中心化身份体系。