【大前端之打通账号系统】passport应该如何落地？

前言

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

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

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

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

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

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

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

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

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

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

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

① 如何实现打通账号系统

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

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

④ H5应该如何做

⑤ Native应该如何做

⑥ 没时间（没意识）

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

用户数据共享

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

① 用户id

② 用户昵称

③ 用户手机

④ 用户密码

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

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

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

差异化处理

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

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

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

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

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

 1 //用户总表 2 //公司用户不一定都是子系统的用户,但子系统用户一定存在与公司用户总表中 3 var 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 ];23 //子系统A中的用户表24 var a_users = [25   {26     id: '1',27     roleId: '1'//游客28   },29   {30     id: '3',31     roleId: '2'//超级管理员32   }33 ];34 //子系统B中的用户表35 var b_users = [36   {37     id: '1',38     title: '教授'//游客39   },40   {41     id: '2',42     roleId: '副教授'//超级管理员43   }44 ];45 //子系统C中的用户表46 var c_users = [47   {48     id: '2',49     address: 'xxxx',50     title: '三甲'//游客51   },52   {53     id: '3',54     address: 'xxxx',55     roleId: '二甲'//超级管理员56   }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即可。