加入sso登录后应用本身的用户表和sso的用户表什么关系

44 次阅读

本文最后更新于 2026年8月21日。

接入 SSO 之后,应用本身(如 Memos)的用户表与 SSO(如 Pocket ID)的用户表并不是替代关系,而是“一对一”或“多对一”的映射绑定的关联关系

应用并不会因为接了 SSO 就删掉自己的用户表,而是通过外键标识(Federated ID / Subject ID)将本地用户与 SSO 身份链接起来。

一、 核心数据模型

在数据库底层,通常存在以下几种映射结构:

1. 两表中的关键字段映射

数据表 关键字段 作用
SSO 用户表 (Pocket ID) sub (Subject / User ID) SSO 系统中该用户的唯一不变标识(通常是一串 UUID)
应用本地用户表 (Memos) id (Local User ID) 应用内部的自增主键/本地 ID,用于关联笔记、标签等数据
应用本地用户表 / SSO 绑定表 sso_sub / provider_id 连接桥梁:存放 SSO 返回的 sub

2. 映射关系示意

Plaintext

【SSO 用户表 - Pocket ID】                【应用本地用户表 - Memos】
┌────────────────────────┐               ┌────────────────────────┐
│ id (sub): "usr_9x2a..."│ ────映射────> │ id: 102                │
│ username: "alice"      │               │ username: "alice"      │
│ email: "alice@a.com"   │               │ sso_provider: "pocket" │
└────────────────────────┘               │ sso_sub: "usr_9x2a..." │
                                         └────────────────────────┘
                                                    │
                                                    ▼
                                         【Memos 业务数据】
                                         (memos, tags, resources...)

二、 两种常见的首次登录与绑定逻辑

当用户通过 SSO 登录应用时,应用内部会触发以下判断流程:

1. JIT(Just-In-Time)自动创建账号(最常见)

  1. 用户点击 SSO 登录,Pocket ID 验证身份后返回 Token/UserInfo,其中包含 sub: "usr_9x2a..."

  2. Memos 拿着这个 sub 去本地用户表查询是否存在 sso_sub = "usr_9x2a..." 的记录。

  3. 未找到记录:Memos 自动在本地 Users 表里插入一条新用户,把 SSO 返回的用户名、邮箱填入,并将 sso_sub 记为 "usr_9x2a..."

  4. 已存在记录:直接登录该本地账号。

2. 手动绑定已有本地账号

如果用户在接 SSO 之前已经在 Memos 里注册了账号:

  1. 允许用户在 Memos 个人设置中点击“绑定 Pocket ID 账号”。

  2. 完成 SSO 认证后,把该 SSO 的 sub 写入当前已登录本地账号的 sso_sub 字段。

  3. 下次直接点击 SSO 按钮,系统匹配到 sso_sub 即可登录原账号。

三、 为什么必须保留应用本地的用户表?

  1. 业务数据外键绑定:Memos 里的每一条笔记、图片、评论,数据库外键关联的都是 Memos 本地的 user_id(如 102)。如果不保留本地用户表,本地的所有业务数据外键都将失效。

  2. 权限与本地配置:SSO 只负责“认证你是谁”,不负责“你在具体应用里的权限”。Memos 需要本地表来存储该用户是 ADMIN(管理员)还是 USER(普通用户),以及用户的本地偏好设置。

  3. 解耦与容灾:如果未来更换或关闭 SSO 系统,应用只需修改映射字段,本地的业务数据和用户资产不会丢失。