需求背景

伴随着业务的不断发展，每个公司的各条业务线子系统之间的耦合也会变得越来越强，此时最初那套各自单独设计的系统之间改造就凸显出来了。

实现系统改造的方案

• 各业务子系统之间实现账号同源改造。即将所有的业务子系统之间的账号进行归纳总结，并放入统一的账号资源池中。进行改造。
• 各业务线子系统之间，进行相互的账号绑定。虽然看似依然相互的各个子系统，因为有着一种绑定的关系而变得互通起来。
• 各业务子系统通过统一的一站式登陆服务进行账号登陆，并将登陆后的凭证关联到各个子业务系统中去，从而实现单点登陆。

基本理解各种方案

• 同源登陆改造。这种做法就是对数据库中原先独立的两个账号数据库或者数据表进行相互补充，最终形成最后一个系统账号表，从而达到账号数据源进行合并的目的。当然也有一些已经成型的系统本身就支持各种数据源打通，也是一个道理，像我们常见的LDAP系统登陆，SMTP系统认证，归根结底它们都是使用同一份数据源进行。

• 各子系统进行相互绑定的账号打通机制。这种也是目前市场上比较常用的方式。比如说我的百度网盘里绑定里各种的三方账号，绑定后就可以利用不同的数据源进行认证登陆。这种OAuth认证方式也是目前对第三方开放平台式账号绑定也是能够解决这种单点登陆的问题的。下面我们就是着重介绍这种oauth认证绑定的机制和原理。
  

下面是我对这种机制的一种理解图示:

• 各个子系统形成一种账号合集，共同使用一个数据认证机制和账号登陆模块。
  以下时个人理解图示:

三种认证方式的比较

• 同源数据系统的登陆改造主要在于数据库方面进行数据表的合并，当数据的规模比较大的时候，或者多个系统之间就比较麻烦，所以两个小系统之间并且数据规模没有那么庞大的时候可以采用这种方式，当然这种方式的可扩展性也是比较差的。
• 三方单向绑定机制，这种情况一般多采用于单项数据绑定，如果想要实现双向数据绑定，那么主系统本身也要实现自己的oauth认证，那么相互绑定对方的access_token旧可以实现来双方的互相绑定机制和互相访问对方的资源问题。
• 多系统采用共同的oauth认证机制，这个比较适用于多个系统进行互通互联的情况。并且扩展性好，账号机制比较完善。建议采用这种方式进行各个系统之间的互通问题。