UIAM统一身份与认证平台
面向人、服务账号与 AI Agent 的统一身份控制面。Kotlin + Spring Boot 4 + Spring Security 7 构建，内置 OAuth2 Authorization Server，16 个数据域、56 张表、77 个 Controller 覆盖从租户隔离到 Agent 工具授权的完整链路，MySQL 与 PostgreSQL 双栈同构。
身份内核不是一层登录壳：租户过滤由 jOOQ VisitListener 在查询层强制，Agent 委托链走 RFC 8693 Token Exchange，工具调用要过 Tool 级授权。
把散落在每个业务系统里的账号、权限与审计，收敛成一个可治理的身份内核。
它到底解决什么问题
四条主线能力，对应四类真实存在的业务诉求。
整合身份信息与权益体系，打通各平台用户孤岛：手机号验证码、社交登录、邀请注册、开放平台授权，一套用户生命周期服务。
企业内部的身份核心：组织、岗位与权限统一管理，内部 SSO 单点登录，员工入职、调岗、离职的全生命周期自动化。
一套平台同时承载内部员工与外部用户，内外身份分域治理、统一策略引擎与安全基线。
为自主运行的 AI Agent 提供身份、凭据、作用域与调用配额，全部行为可追溯、可即时吊销。
能力一览
- OAuth2.1 / OIDC 内置授权服务器：授权码、客户端凭证、刷新令牌、Token Exchange 全支持
- 多租户 + 多空间（tenant / space）强隔离，JWT 的 tenant_id 是唯一可信源
- RBAC 细粒度授权：功能权限 + 数据权限双轨，权限变更实时生效
- WebAuthn / Passkey、Magic Link、TOTP MFA、设备管理、IP 规则、敏感词策略
- Agent IAM 四大支柱：机器主体 → 委托链 → 多跳传递 → MCP 工具授权
- 连接器生态：企业微信、微信开放平台、小程序、GitHub、Google 开箱接入
这不是 PPT 里的产品
下面的数字来自 uiam-coplit 仓库的真实代码：模块、数据表、接口与能力项。
技术栈
功能清单
6 个业务域、43 项具体能力。每一项都对应代码里真实存在的实现。
多租户与空间隔离
uiam-core · 01-tenant · 02-space租户边界即安全边界，过滤在查询层强制而不是靠人记得写 WHERE。
- 租户管理：租户 CRUD、租户配置、租户配额、租户设置与租户发现
- 空间管理：租户下多空间，空间成员、空间安全设置与公开空间
- TenantScopedTables 注册表把 45 张表标记为租户作用域表，集中声明
- TenantScopeVisitListener 在 jOOQ 查询层检测缺失租户谓词，可切 DETECT_LOG / DETECT_THROW
- JWT 中的 tenant_id 是唯一可信源，请求头声明不匹配直接 TenantMismatchException (403)
- UserContext ThreadLocal 每请求清理，避免跨请求泄漏
- runAsSystem / runWithoutTenantFilter 显式绕过通道，绕过行为本身进审计
认证与凭据
uiam-authn · uiam-protocol从密码到 Passkey 到无密码，一条链路上多种凭据强度共存。
- 用户名密码登录：密码策略、密码历史、账户锁定、密码重置
- OAuth 2.1 全授权流程：授权码、客户端凭证、刷新令牌、Token 撤销
- OIDC 标准端点：Discovery、JWKS、授权、同意页、Token、Introspect
- WebAuthn / Passkey 无密码认证，配合设备管理与设备策略
- Magic Link 邮件无密码登录，验证码与人机校验
- TOTP MFA 注册、校验与备用码，MFA enrollment 流程可对接外部系统
- 应用密钥（Application Key）与 JWT 流转，供服务端到服务端调用
- 个人 API Key 与用户级 API Key 管理，支持 introspect 校验
授权与权限
uiam-authz · 07-authzRBAC 打底，数据权限补位，Token Exchange 做权限裁剪。
- 角色管理与权限管理，角色-权限、用户-角色关联关系
- 数据权限：Sys 数据权限服务按范围计算可见数据
- 租户级权限与空间级权限分层，用户资源与用户权限视图
- Token Exchange（RFC 8693）：impersonation 与 delegation 双模式
- 委托时取「应用权限 ∩ 用户权限」交集，maxPermissionLevel 上限裁剪
- act claim 表达「谁代表谁」，支持多跳嵌套委托链
- 菜单与应用分组：应用分组、用户应用、应用空间绑定
Agent 身份与工具授权
uiam-agent · 16-agentAI Agent 是一等公民主体，不是借用人类的令牌偷偷干活。
- MACHINE subject_type：服务账号与 Agent 不再伪装成 USER，令牌带 principal_type=machine
- 机器主体可直接分配角色，assignToMachine / batchAssignToMachines 批量授权
- MCP Server 端点：Agent 通过标准 MCP 协议接入，凭据与作用域由 UIAM 下发
- agent_tools 工具注册表，工具调用前校验调用方是否持有该工具权限
- @RequiresToolPermission 注解把工具级授权写进代码而不是写在文档里
- Agent 调用配额与速率限制，超配额立即失败
- 全链路审计：谁委托给谁、调用了哪个工具、用了哪些权限，可完整回放
身份源与社交连接
uiam-connector · 10-connector国内 IM 生态与国际社交账号，同一套连接器抽象。
- 企业微信连接器：扫码登录、通讯录身份源
- 微信开放平台连接器：微信登录与用户信息获取
- 微信小程序连接器：小程序登录态换取统一身份
- GitHub / Google OAuth2 社交登录
- 连接器统一管理后台：配置、启停与回调治理
- 身份源（Identity Source）抽象，外部身份可映射为本地身份与身份标签
审计、治理与运营
uiam-audit · uiam-server一切行为留痕，运营面可以直接用来管平台。
- 审计日志：结构化事件记录，支持按主体、租户、时间检索
- 安全告警：异常登录、租户越权等风险事件单独标记 SECURITY / FAILURE
- 系统日志与登录历史，用户可自查自己的登录足迹
- 系统初始化与系统配置：首次安装引导与运行时开关
- 通知模板与 Webhook：事件驱动对外推送
- 字典、菜单、公告：后台运营所需的元数据管理
- 配额与用量：租户配额、用户配额与使用统计
- 敏感词与 IP 规则：内容合规与访问来源控制
接口契约
12 个代表性接口。列在这里的是对外契约的骨架，完整定义随部署提供。
/oauth2/token令牌端点：授权码、客户端凭证、刷新令牌、Token Exchange 共用
/oauth2/authorize授权端点：承载登录、MFA 二次校验与授权同意
/.well-known/openid-configurationOIDC Discovery：客户端自动发现端点与能力
/oauth2/jwks公钥集：业务侧本地验签，无需回源
/oauth2/introspect令牌自省：不可离线校验的场景使用
/oauth2/revoke令牌撤销：登出、风控与凭据轮换触发
/api/v1/authn/passkey/registerWebAuthn / Passkey 注册与凭证绑定
/api/v1/authz/token-exchangeRFC 8693 委托与模拟，权限取交集裁剪
/api/v1/agents/{id}/tools/{tool}/invokeAgent 工具调用入口，经 @RequiresToolPermission 校验
/api/v1/tenants/{code}/spaces租户下的空间列表，查询自动带租户谓词
/api/v1/audit/events审计事件检索：按主体、租户、时间维度
/api/v1/connectors/{kind}/callback身份源连接器回调统一入口
一次真实调用
接口长什么样，比接口清单更能说明问题。
01$ curl -X POST https://id.zhenbei.tech/oauth2/token \02 -d grant_type=urn:ietf:params:oauth:grant-type:token-exchange \03 -d subject_token=$USER_TOKEN \04 -d actor_token=$AGENT_TOKEN \05 -d audience=uniscrm-api0607{ "access_token": "eyJhbGciOiJSUzI1NiIs...",08 "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",09 "expires_in": 900,10 "act": { "sub": "agent:sales-copilot", "principal_type": "machine" } }契约纪律
接口是承诺，不是实现细节的暴露。这三条规则我们一直在守。
破坏性变更走大版本，提前一个版本周期公告。已发布的接口不会因为内部重构而改语义。
错误码语义化而不是笼统 500，调用方（包括 AI Agent）能据此决定是重试还是放弃。
默认返回结构化数据而不是给人类看的文本，这样 AI 能直接读，不需要人截图转述。
功能模块
5 组、14 个代码模块，全部来自 uiam-coplit 仓库的真实目录结构。
uiam-server-kotlin/主体建模、组织架构与用户生命周期。
uiam-core公共内核：租户上下文、请求上下文、租户作用域表注册与查询助手
uiam-core/{api,biz}uiam-dept组织与部门：树形组织、岗位账号、成员归属与员工-组织关联
uiam-dept/{api,biz}03-identity / 04-organization身份与组织的数据域：用户档案、身份标签、外部成员、组织关系
db/changelog/migrations/所有让「谁在访问」得到证明的部分。
uiam-authn认证：密码登录、验证码、Magic Link、Passkey、会话与登录历史
uiam-authn/{api,biz}uiam-protocol-oidcOIDC 协议：Discovery、JWKS、授权端点、同意页、Token 签发与撤销
uiam-protocol/uiam-protocol-oidcuiam-protocol-core协议内核：Client 注册、授权同意、Scope 与令牌模型
uiam-protocol/uiam-protocol-coreuiam-connector-*身份源连接器：wecom / weoa / weopen / weapp / github / google
uiam-connector/决定「能做什么」以及「什么情况下不允许」。
uiam-authz授权：角色、权限、数据权限、Token Exchange 与权限交集裁剪
uiam-authz/{api,biz}uiam-audit审计：结构化事件流、系统日志、安全告警与合规留存
uiam-audit/{api,biz}13-security-ext / 14-sensitive / 15-ip-rule安全扩展：密码历史、敏感词、IP 规则、设备策略、配额
db/changelog/migrations/把 IAM 边界从「人」扩展到「AI Agent」。
uiam-agentAgent 主体、MCP 端点、agent_tools 注册与 ToolExecutionService
uiam-agent/{api,biz}16-agentAgent 数据域：机器主体、委托链、工具授权相关表
db/changelog/migrations/16-agent/多租户 SaaS 的运营面。
uiam-server装配层：租户与空间治理、系统初始化、系统配置、字典、菜单、公告、Webhook
uiam-server/uiam-jooq代码生成：从 Liquibase changelog 生成 Tables / Record 类型
uiam-jooq/分层设计
从接入到运行时，每一层负责什么、用什么实现。
OAuth 2.1 / OIDC / Token Exchange (RFC 8693) / JWKS / Discovery / WebAuthn
用户、组织、服务账号、Agent 四类主体统一建模，subject_type 区分 USER / MACHINE
RBAC + 数据权限，权限按租户 / 空间双重隔离，Token Exchange 取交集裁剪
jOOQ TenantScopeVisitListener 查询级强制租户谓词，45 张租户表集中注册
MFA、Passkey、设备策略、IP 规则、密码历史、风险告警、系统 JWT 密钥轮换
结构化审计事件流，租户违规写 SECURITY / FAILURE 级日志
Kotlin 2.2 · Spring Boot 4 · Spring Security 7 · jOOQ · Liquibase · 虚拟线程
关键流程
最重要的几条路径，逐步拆开看。
标准 OIDC 授权码登录
业务系统把用户交给 UIAM，拿回的是可校验的令牌而不是一份用户表。
- 1
业务应用重定向到 /oauth2/authorize，携带 client_id、scope、redirect_uri
- 2
UIAM 判断当前会话：未登录则展示登录页（密码 / 验证码 / Passkey / 社交）
- 3
命中 MFA 或设备策略时插入二次校验，校验通过才算认证完成
- 4
回到授权同意页，用户确认授权范围
- 5
下发授权码 → 换取 access_token / refresh_token / id_token
- 6
业务侧用 JWKS 本地校验令牌，P99 内完成，无需回源
Agent 委托链（Token Exchange）
Agent 代表用户干活时，令牌里写明「谁代表谁」，权限取交集而非并集。
- 1
Agent 以自身 MACHINE 身份取得主体令牌，principal_type=machine
- 2
携带用户令牌发起 urn:ietf:params:oauth:grant-type:token-exchange 请求
- 3
TokenExchangeServiceImpl 计算「应用权限 ∩ 用户权限」并按 maxPermissionLevel 裁剪
- 4
新令牌写入 act claim，记录委托者，多跳场景 act 可嵌套
- 5
Agent 用新令牌调用业务 API，资源端读取 permissions claim 做实际授权
- 6
整条链路写入审计，包含委托关系、工具与权限快照
租户隔离强制校验
租户边界不靠 review 保证，靠查询层的监听器。
- 1
请求进入，TenantContextFilter 从 JWT 解析 tenant_id 写入上下文
- 2
若请求头声明的租户与 JWT 不一致，直接抛 TenantMismatchException (403)
- 3
jOOQ 执行时 TenantScopeVisitListener 检查 SQL 是否命中租户作用域表
- 4
缺 tenant 谓词的查询按配置记录安全日志或直接抛错
- 5
确需跨租户的系统级操作走 runAsSystem 显式绕过，并留审计
- 6
请求结束清理 UserContext，防止线程池复用泄漏
技术栈
性能与规模
这些数字不是估算，是从代码与运行配置里读出来的。每一条都注明了它的实际含义，避免被当成宣传口径。
uiam-coplitJWKS 本地验签，业务服务不需要回源身份中心
集中注册 + 查询层监听器，缺谓词可配置为直接抛错
MySQL 8 与 PostgreSQL 同一份代码，迁移按方言分目录维护
Liquibase 版本化，重复执行结果一致，失败可回滚
act claim 嵌套表达多跳委托，权限逐跳取交集而非并集
企微 / 微信开放平台 / 小程序 / 企微 OA / GitHub / Google
仓库里数得出来的事实
下面每一项都能在 uiam-coplit 里核对：模块、数据表、接口与能力项。我们判断一件事「做完没有」的方式，就是看这些数字有没有变。
安全与合规支撑点
UIAM 在安全上具体做了什么、边界画在哪里。每一条都标注了对应的实现位置，方便核对。
请求头声明的租户与 JWT 不一致直接 403；跨租户操作必须走显式绕过通道，绕过行为本身进审计。
TenantMismatchException · runAsSystem密码策略、密码历史、账户锁定、TOTP MFA、Passkey、Magic Link 可按租户与场景组合。
uiam-authn · 13-security-ext设备管理、设备策略、IP 规则与敏感词策略，构成登录与内容的双层防线。
15-ip-rule · 14-sensitive系统 JWT 签名密钥支持轮换，旧令牌在有效期内仍可验证，轮换不停机。
uiam-protocol-core审计事件按主体、租户、时间结构化落库，安全事件单独分级，满足合规取证。
uiam-auditAgent 凭据独立于人类，工具调用逐次校验权限与配额，可即时吊销全部授权。
uiam-agent · agent_tools数据停在哪一层
数据边界由产品形态决定，不是一个可以随手打开的开关。这是四条业务线共同的判断。
端侧产品的最小边界。这一层的数据在设计上就没有上传通道，不是靠开关关闭的。
- legdger 全部账目：本机加密存储，云端只有密文
- legdger 端侧 AI 统计与问答：推理在设备内完成
- NewTool 桌面与 wasm 形态：算法内核无 IO，数据不出进程
- pxc 抓包流量：内核跑在本机，不经第三方服务
私有化交付的边界。模型、向量、业务数据与审计记录全部部署在客户自己的网络里。
- Uniclaw 记忆与知识向量：自建 Milvus，不出内网
- Uniclaw 模型服务：可对接私有化部署的兼容协议服务
- UIAM 身份与审计数据：整套部署在客户网络边界内，可完全离网
- Uniscrm 素材与媒体：对象存储可对接客户自有 OSS
- Unilearning 课件与学习记录：单容器交付，数据自主
唯一需要外部网络的是同步与外部通道，且传输内容是加密密文或已脱敏的消息。
- legdger 跨设备同步：只上传最新密文，服务端不积历史
- Uniscrm 企微通道：与企业微信官方接口通信，走官方存档能力
- Uniclaw 通道：飞书 / 钉钉 push API，内容按租户隔离
- NewTool 远程调用：经 MCP 传输，算法内核本身不发起网络请求
公司级安全原则
不管哪条业务线，这六条是共同的底线。
凡是能写死在编译器、框架或查询层里的约束，就不写进文档让人记住。租户隔离由查询层监听器强制，域边界由 Go 的 internal 机制在编译期拒绝。
jOOQ TenantScopeVisitListener · Go internal 墙敏感数据默认留在用户设备或客户网络内。四条业务线全部支持私有化交付，端侧产品（legdger）连 AI 分析都不出设备。
legdger 端侧 AI · Uniclaw 自建 Milvus · Unilearning 单容器Agent 不共用人类凭据，服务端不硬编码长期密钥，端侧接入走可撤销令牌。任何凭据都能被单独吊销而不影响其他主体。
UIAM MACHINE 主体 · OSS STS AssumeRole · ledger-cli 令牌认证、授权、工具调用、抓包调试全部产生结构化记录。不是为了合规而记，是为了出事时能回放。
uiam-audit · collaboration-logger · pxc 会话记录委托关系用 act claim 表达「谁代表谁」，权限逐跳取交集。审计里能回答「哪个用户授权了哪个 Agent、调用了哪个工具、用了哪些权限」。
RFC 8693 Token Exchange · agent_tools 注册表数据库变更走版本化迁移，重复执行结果一致；应用发布是单镜像替换，回滚就是换回上一个镜像。
Liquibase · 各域方言迁移 · Docker 单镜像部署与集成
全部产品线均支持私有化交付，具体形态因产品而异。
默认交付形态：整套身份内核部署在客户自己的网络边界内。
- 单套 Spring Boot 服务 + MySQL/PostgreSQL + Redis
- Liquibase 版本化迁移，升级幂等可回滚
- 无外部 SaaS 依赖，可完全离网运行
同一份代码在 MySQL 与 PostgreSQL 上运行，方言差异由 jOOQ 与迁移文件吸收。
- application-mysql.yml / application-pg.yml 双 profile
- 迁移按方言分目录维护，发布后不再修改历史版本
- jOOQ 代码生成从 changelog 直接生成类型安全的数据访问层
业务系统接入不需要改自己的用户体系，只需信任 UIAM 签发的令牌。
- OIDC / OAuth2.1：标准客户端库直接接入
- JWKS 本地校验令牌，无需每次回源
- API Key / Application Key：服务端到服务端场景
- MCP：AI Agent 场景
可与 API 网关配合，把认证前移到流量入口。
- Higress 集成方案（docs/integration/higress）
- 令牌校验在网关层完成，业务服务只处理授权后的身份
- 与 UIAM 的 Uniclaw、Unilearning 产品线已打通
方案对比
同一件事，不同的做法。左栏是我们的选择，右栏是常见的替代方案——差别通常不在功能表上，而在边界画在哪里。
谁会感觉到变化
功能清单说服不了人，角色视角可以。下面是四类角色接入前后的真实差别。
每个业务系统各自维护账号体系，权限口径不一致，接一个新系统就要再对一次登录
标准 OIDC 一次接入，令牌与权限模型全局统一，新增系统只是多注册一个客户端
答不出「谁在什么时候以什么身份访问了什么」，越权只能靠事后发现
结构化审计事件流可对接 SIEM，租户越权直接写 SECURITY / FAILURE 级日志
登录逻辑在每个服务里重复实现，改一次密码策略要改 N 个仓库
认证与授权全部收敛到身份内核，业务服务只读令牌里的 claims
员工离职后权限残留，回收要人工逐个系统清理，总有漏网的
离职即触发全量权限回收，实时生效，无需逐系统操作
版本与路线
已发布的写清楚交付了什么，开发中的写清楚正在做什么，规划中的写清楚打算做什么。已发布的条目不会再被推翻。
v1.0已发布基础内核- 身份内核与多租户隔离
- OAuth 2.1 / OIDC 授权服务器
- RBAC 角色与权限管理
- MySQL / PostgreSQL 双方言
v1.2已发布Agent IAM- MACHINE 主体建模与服务账号
- RFC 8693 委托链与多跳传递
- MCP 端点与工具级授权
- Agent 调用配额与速率限制
v1.4开发中治理增强- 权限变更实时推送（不再等下次登录）
- 审计事件流对接 SIEM
- 系统 JWT 密钥轮换不停机
- 策略引擎可编程化
v2.0规划中联邦与策略- 跨租户联邦身份
- ABAC 策略语言
- 身份数据出境合规策略
- 第三方应用市场
集成与对接对象
UIAM 需要和谁打交道、用什么方式。
扫码登录与通讯录同步，组织架构直接作为身份源
微信登录与用户信息获取，支撑 To C 会员体系
小程序登录态换取统一身份，多端会员归一
国际社交账号 OAuth2 登录，供内部工具与外部协作
认证前移到流量入口，网关层完成令牌校验后透传身份
三条业务线共用同一身份内核，Agent 凭据与工具授权由 UIAM 下发
落地场景
这套东西在真实业务里怎么用。
一个集团下多个子公司、多套系统，共用一套身份内核但数据互不可见。
- 租户隔离子公司，空间隔离业务系统
- 员工一次登录通行所有内部系统
- 离职即时回收全部权限，实时生效
多端 App、小程序、Web 共用一套会员身份与登录方式。
- 手机号验证码 + 微信 + 社交登录统一收敛
- 会员标签与身份标签统一维护
- 开放平台授权给第三方应用
Agent 要读订单、要发消息，但不能拿着开发者的凭据为所欲为。
- Agent 拥有自己的 MACHINE 身份与可撤销凭据
- 委托链可追溯「哪个用户授权了哪个 Agent」
- 工具级授权决定 Agent 能调哪些接口
金融、政企场景需要每个人的每次访问都可解释。
- 结构化审计事件流可对接 SIEM
- 敏感词、IP 规则、设备策略多层防控
- 系统 JWT 密钥支持轮换，不停机
常见问题
需要。LDAP 解决目录存储，UIAM 解决的是现代协议（OIDC / OAuth2.1）下的统一认证、细粒度授权、多租户隔离与 Agent 身份，并可作为外部身份源的上层控制面。
把身份、Agent 与私域的复杂度，交给一套可治理的内核
无论你是要替换现有的 IAM、搭建 Agent 中台，还是想把企微私域真正运营起来——先从一次 30 分钟的架构沟通开始。我们会先判断问题是不是我们擅长解的那类，不合适会直接说。