现有三个不同的系统，如何整合成单点登录 sso？

有同样的疑惑。

sso系统要有一个总的用户表，然后各子系统用户表关联sso系统用户表ID

@黄威 所以，子系统的用户表还得插入用户数据，并添加一个字段去记录 sso的用户ID，是这个意思吗？

国外，一般SSO都是买Auth0或者Okta的服务来整合的，不知道国内有没有类似的服务。不然自己写SSO会写到头发掉光的……

整合表的时候，，，应该搞一个 uuid 来区分用户了，不能用自增 ID 了吧，，

@largezhou 原先系统A的用户表去加字段，记录 uuid 吗？

不知道你们公司的业务逻辑是什么，如果可以的话，最好的方案是统一用户中心。之前碰过类似的项目，最后都是统一使用这个方案。

也就是说，不过现在是系统 A,B,C 或者以后可能会 E,F,G 都统一使用一个用户中心来管理用户，如注册、登录。

统一了用户中心，其他就好办了：

1. 合并用户数据，将三个系统中的用户合并起来；
2. 更改三个系统的登录和注册入口，都链接到新的「统一的用户中心」。

否则后面随着系统的增多，同步各个系统之间用户数据，将难度倍增，复杂度会高到你想辞职。

@Summer 那原先的系统 A,B,C 中，有关联用户id 的表都得手动去修改咯

我们使用的简单的oauth2的机制, 类似微信授权登录的实现, 用户中心只保留基本的用户信息. 每个用户有一个唯一键(姑且也叫openid) , 每个系统的用户表都有一个openid的字段. 用户需要登录就重定向到用户中心的授权登录(或者静默登录)页. 然后带上code到回调地址. 每个系统都有一套自己的appid和secret 通过code 去用户中心code登录接口登录(当然数据包使用了签名机制), 拿到基本信息和openid 剩下的就好办了..

迁移时你可以使用每个系统自己的appid和user表的id来为每个用户生成这个openid 然后去新系统注册 这样通常来说不会出现重复 当然如果你有类似手机号这样的唯一标识作为每个系统打通的方案更好 但是还是要在注册到用户中心时还是生成一个openid返回给每个系统并保存 不然后续万一修改手机号什么的 就有更多耦合了

你这每个用都有自己的数据 而且存的都是user_id 你合并表 但是你原来用户的数据也得修改

@pi_phq :joy:你细看一下我的表述.

上家公司后台系统部比较多，做过Summer说的那种用户中心系统，我们叫做cas。登录都是调用的cas的登录页面和接口啥的。登录成功之后，用户信息存放在redis里面。每次进入新系统都会去redis里面看下是否有该用户的信息。在cas里面，还管理了用户的各个后台系统权限什么的。用户信息什么的，也都是存在cas的数据库里面，没有存在各个后台系统里面。

你可以产考一下ucenter， 3个系统每登陆一次就会在ucenter 注册。

@zymaozZ 每次进入新系统都会去 redis 里面看下是否有该用户的信息，新系统到了 cas 根据什么信息去判断尼？这个信息从哪里读取尼？

id用数据库自增id这就是坑爹的设计。既然这样了，那就在每个系统做一个uid映射吧，新生成的id都用统一的。

用JWT做登录就好

@英雄没有斗篷 cas里面管理每个后台系统，每个后台系统在cas系统里面有自己的唯一标识的。redis里面存储的key是用户的id，value是用户信息还有各个系统的权限啥的

做一个鉴权系统

• 公司内部所有账号都通过鉴权系统进行分配和删除
• 公司内部系统的 账号相应的角色权限可以在鉴权系统进行设置
• 公司内部系统需要登陆的时候 直接跳到鉴权进行登陆，登陆成功返回token和账号相应角色的权限系统
• 一个子系统登录所有子系统都不需要登陆，redis存入token，token写入cookie，cookie设置domain为父级，比如子域名 a.sss.cn b.sss.cn ，设置为 将domain设置为sss.cn存入token
• 人员新增离职或者权限变更就全统一在鉴权设置

JWT配合redis 就可以实现 多平台 一个token的单点登入了啊

@Summer 不同系统中的用户组和权限怎么处理？是在子系统中维护用户组和权限。还是子系统的用户组和权限都又ucenter中心来维护呢？

哈哈最近也在搞单点登录，现在的搞法是中心平台登录后，根据uuid登录子系统账号，这样只改动登录逻辑其它的不用动，但是用户同步还有很多蛋疼的地方，楼主有什么好的办法别忘了回来分享啊

authing.cn 有 CIAM（外部用户管理） 和 EIAM（组织单点登录平台）两种服务，可以试一试

仔细想了一下你的这个需求，就感觉很怪，系统 A B C 都有用户表，那是不是会有一个用户 M ，既能在 A 系统中的用户表（假如在 A 系统中的用户表 id 为 1），又能在 B 系统的用户表（在 B 系统中的用户表 id 为 2 ），不知道这个情况你们是怎么处理的，相当于一个用户有两个身份证，那如果有这个情况，而你们又没做什么处理的话，那就算整合到一个表中做 sso，也很难处理这个身份

我的想法同Summer老师一样，有个统一的用户中心负责验证以及分发登录token，这样对你系统的修改最小，只需要单独实现用户中心，以及对每个系统的登录、注册、退出登录等设计登录的接口进行修改。具体步骤如下

1. 实现一个用户中心，维护一个索引表，记录UUID为唯一标识。
2. 要实现生成UUID的方法提供调用（该方法还会记录UUID）。
3. 实现通过UUID生成token的方法提供各个系统在涉及登录逻辑处调用。
4. 实现一个中间件，负责通过获取请求的token去用户中心校验，通过才能进行下一步
5. 各个系统集成中间件以及用户中心的方法。

各个系统在注册用户时需要调用生成UUID方法，去记录UUID，把UUID作为一个全局用户唯一标识

未必需要集中式的用户中心，也可以设计程成多中心。每个站点都加上oauth，其他站点注册为这个站点的应用，实现他站登录，各自维护自己的用户表，不用考虑太多用户迁移的逻辑问题。业务上也更加平滑。站点之间跳转时，可以用带code跳转，实现自动带上来源站的登录状态。

可以试试开源单点登录平台 Casdoor： github.com/casbin/casdoor ，支持OAuth, SAML、联合登录等身份认证方式，具有Web UI ，支持多租户，支持 GitHub、Google、QQ、微信、钉钉等十几种第三方登录

我这遇到了这样的情况，暂时考虑的就是建立一个用户中心E，根据独立的信息（比如身份证，手机号）作为识别，然后把几个系统（A、B、C）的用户统一到E里，同时在ABC分别记录下对应E里面的id，如果身份证重复就用同一个e_id。然后各自维护，只是登录时统一走E的通道登录判断，成功后各自生成token。 这么搞的话ABC不需要太多考虑互相间的关系问题还有token问题，但是前端接起来感觉容易乱。然后E里的用户信息或者其他修改也需要及时反馈给ABC进行同步更新。 暂时也很犹豫这种方式是否合适，怕做出来遇到不好解决的问题。。。