Ksuser文档

主题

内部服务用户独特信息设置 ​

目标 ​

每个内部服务都可以基于 SSO 标识维护自己的用户配置，不和其他服务串数据。

推荐原则：

  • 全局身份由 Ksuser 认证中心负责
  • 服务内偏好、角色、主题等由各服务自管
  • 跨服务唯一键使用 sub

为什么用 sub ​

在当前实现下，sub 是按 client_id + 用户 生成的稳定标识。

这意味着：

  • 同一用户在同一个服务里 sub 稳定不变
  • 同一用户在不同服务里 sub 不同
  • 服务间无法直接通过 sub 互相关联，降低横向追踪风险

推荐数据模型 ​

每个服务单独建表，按 sub 建唯一约束：

sql
CREATE TABLE service_user_profile (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_sub VARCHAR(128) NOT NULL,
  display_name VARCHAR(100) DEFAULT NULL,
  theme VARCHAR(32) DEFAULT 'light',
  locale VARCHAR(32) DEFAULT 'zh-CN',
  extra_json JSON DEFAULT NULL,
  created_at DATETIME NOT NULL,
  updated_at DATETIME NOT NULL,
  UNIQUE KEY uk_user_sub (user_sub)
);

登录后的落库流程 ​

  1. 服务完成 SSO code 换 token。
  2. 用 access_token 调 /sso/userinfo 得到 sub。
  3. 用 sub 查询本服务用户表。
  4. 若不存在则初始化一条新记录。
  5. 之后所有“个性化设置”都按 sub 更新。

首次登录初始化建议 ​

从 userinfo 读基础字段，初始化你自己的档案：

  • preferred_username -> 初始展示名
  • picture -> 初始头像
  • email -> 联系邮箱（仅在请求了 email 时）

但不要把这些字段当成最终数据源：

  • 这些是“登录时快照”
  • 服务内用户后续可以改自己的展示名/主题/偏好

多服务隔离建议 ​

  • 不要共享同一 client_id
  • 每个服务独立一个 SSO 客户端
  • 每个服务独立维护 service_user_profile
  • 如需集团级画像，走显式用户同意和后台映射，不要直接拼接不同服务 sub

常见误区 ​

  • 误区：拿 OAuth2 的 openid/unionid 当 SSO 主键
    • 建议：SSO 服务统一使用 sub
  • 误区：把 id_token 当业务会话长期使用
    • 建议：只用于登录断言，业务会话由服务自己签发
  • 误区：多个服务共用同一个 client
    • 风险：权限边界和审计边界模糊，难以定位问题