前言

之前接入百度账号系统的时候写了一篇博客做研究：【大前端】认识单点登录，出来后才发现，很多小公司其实并没有将账号系统打通，总结一下账号系统没通的原因是：

① 最初设计就没想过身份认证应该做整合

② 后续业务中逐渐发现登陆系统过多，但是迫于业务压力以及整合复杂度，于是再搁置

这个就是技术债了，这种基础服务的技术债不及时还，会导致不可忽视的工程问题：

① 账号系统相关需求越来越多（登录、注册、个人信息管理......），每次都需要重新做

② 用户数据没有一个收口的地方，如果数据量一起来要整合、分析就难了（比如一些系统使用账号登录、一些系统使用手机登录，如果想全部改造成以手机登录就很难做到）

③ 账号系统不通（所有应用需要共享一个身份认证系统），会导致频道不通问题，比如多数情况下钱包也是一个独立的频道，而一个子频道产生订单后，需要去钱包频道完成支付（http --> https）这个时候如果需要重新登录的话是十分操蛋的行为

要解决以上问题，就要打通账号系统，这个有两个必要条件：

① 所有应用系统都直接依赖与同一套身份认证系统

② 所有的子系统都得改造通过上述认证系统认证，也就是之前文章说的，要能够识别ticket

然后真实的情况是比较失望的，之前已经有很多子系统各自为政了，而且数据库都不一致，所以更多的时候我们的问题是：

① 如何实现打通账号系统

② 新业务如何接入账号系统

③ 老业务如何接入账号系统

④ H5应该如何做

⑤ Native应该如何做

⑥ 没时间（没意识）

文中内容皆是自我知识总结，并且我是前端，如果文中有误请您指出。

用户数据共享

实现账号系统打通的前提是用户数据共享，分散的用户管理是账户系统打通的拦路虎，用户数据不能共用，各个系统之间根本没任何联系，所以要严谨子业务独立创建用户，公司的所有系统必须依赖于同一张用户信息表，这是一张不包含任何业务的表，可能包含以下数据：

① 用户id

② 用户昵称

③ 用户手机

④ 用户密码

⑤ 头像&性别&出生年月&身份证&头像......

比较差的情况是各个子系统的登录注册完全独立，这样用户便形成了信息孤岛，将各子系统的用户公共信息迁移到一张表是第一步。

PS：这种各个子系统独立的情况，甚至可能出现用户表中存在重复手机号的情况

差异化处理

如果所有子系统接共用同一张用户表，那么第一个问题马上就出来了，差异化如何处理，比如：

① 子系统A用户具有角色权限功能，比如管理员、游客、超级管理员

② 子系统B用户用于医院角色，具有职称属性，正教授、副教授、讲师

③ 子系统C为一个医院机构，具有地址、三甲等属性

这个时候需要各个子系统自己维护一个用户角色表，比如这样：

users = [ 4 { 5 id: '1', 6 phone: '13579246810', 7 name: '昵称1', 8 infos: '其它公共信息' 9 }, 10 { 11 id: '2', 12 phone: '13579246811', 13 name: '昵称2', 14 infos: '其它公共信息' 15 }, 16 { 17 id: '3', 18 phone: '13579246812', 19 name: '昵称3', 20 infos: '其它公共信息' 21 } 22 ]; a_users = [ 25 { 26 id: '1', }, 29 { 30 id: '3', } 33 ]; b_users = [ 36 { 37 id: '1', }, 40 { 41 id: '2', } 44 ]; c_users = [ 47 { 48 id: '2', 49 address: 'xxxx', }, 52 { 53 id: '3', 54 address: 'xxxx', } 57 ];

这个时候不同的系统差异化就能得到处理。有一种比较不好的情况是，之前子系统用户表中就已经包含了业务信息比如（roleId），这个时候要分离就比较烦了

很多朋友不关注数据库设计的三范式，但真正遇到问题的时候才能深刻认识到第三范式能带来什么好处！

用户数据打通后，便可在此基础上进行下一步工作了！！！

统一认证系统

所有的passport系统（统一登录认证系统）核心功能就两个：

① 登录

② 授权或者鉴权

PS：因为我们团队暂时所有应用全在一个主域下，就暂时没考虑跨域的情况。

我们这里的实现方案是这样的：

① 子系统（a.domain.com）访问需要登录的接口，未登录则跳到统一登录页面（passport.domain.com）

② 用户完成登录后，server端向主域cookie写入ticket，跳回子系统a.domain.com

③ 子系统a.domain.com访问接口，server端发现带有ticket，便去passport服务器校验，成功则返回给子系统server用户id

④ 子系统往自己域名写入cookie，有效时间内不再走passport鉴权

同理，如果子系统b.domain.com进行系统，因为主域上已经有ticket，便会直接进入a的业务系统，获取和该业务系统相关的权限控制等信息了

这里举个例子，用户调用获取基本信息接口getInfo整个流程：

① 因为接口需要登录状态，所以先到passport登录

② passport登录后往主域cookie种入标志ticket，并且重新跳回子系统

③ 子系统访问getInfo接口，发现主域中具有ticket标志，则拿着这个标志去passport校验，校验成功返回用户信息

④ 子系统根据基础用户信息，拿着用户id将更多的信息筛选出来，比如roleId，返回给前端H5页面

这个即是统一的认证系统，而这里有一个容易被忽略的关键是：

子系统获取主域中的ticket，去passport校验有效性

这句话的意思是，每个子系统都必须能够识别passport机制的ticket，意思是每个子系统都必须接入passport

而接入的方式其实很简单，几个步骤就可以做完，比如说：

① passport方提供一个接口，getUserInfo，如果主域中具有cookie信息便能返回用户信息，如果没有就返回错误码（未登录）

② 业务系统如果需要登录信息的话，server首次直接根据ticket去passport拿用户信息，如果拿得到就在本地存储session，如果拿不到就直接返回passport的错误码即可

③ 业务系统如果拿到用户信息，可以自己做简单包装，也可以什么都不做，全看业务需求

结语 关于退出登录

关于退出登录，其实比较简单，稍微改下各个业务系统的判断规则，必须ticket在才考虑本身系统的session是否存在，每次退出操作，直接调用passport的登出接口删除主域ticket即可。

关于APP与H5鉴权

更多情况下我们会有APP使用Webview打开H5页面的情况，这里要做登录态处理的话，便需要App请求passport接口后保存ticket，当打开webview时直接往主域注入ticket即可。

当然，这里的前提是，子系统已经接入了passport。

关于跨域部分因为实际工作没有碰到暂时不涉及，这里知识点根据后续接入程度可能会做修改。

关于代码的简单实现大家可以看看这篇文章：实现大同小异