统一的认证模块

用一个现实中的例子做比较。旅游景点，内部有许多独立的景点，，都可以在各个景点门口单独买票。这种买票方式很不方便，需要在每个景点门口排队买票，钱包拿进拿出的，容易丢失，很不安全。于是绝大多数游客选择在大门口买一张通票（也叫套票），就可以玩遍所有的景点而不需要重新再买票。他们只需要在每个景点门口出示一下刚才买的套票就能够被允许进入每个独立的景点。

统一的TOKEY认证，可以使用新建一个TOKEN中心…或者以A或者B的TOKEY为准。。改造另一个模块的认证代码…主要涉及登录，注册，登录检查，登出等功能..

这个适合比较紧密的内部模块区间实现..适合新设计的模块

TOKEN交换

现实中的例子。。比如坐公交车，可以使用通用的现金方式。也可以提前将现金换购成IC卡，刷卡更方便快捷

当给手机充值时，IC卡又不起作用了。需要把现金换成充值卡，才可以生效…

是一种1对多的关系..

又像是护照，每个国家的效力都不一样..当进入另一个国家的时候，为了方便，可以换成另一国的ID卡来使用…

当在A中登录，生成TOKEN。。当转在B中时，将其换为B的TOKEN。此种方式对双方影响最小。可以独立的登录注册等..

但当双方用户名不同时，需要建立一个绑定。。从A转往B时，需要把A的用户名转为B的用户名登录。。

双方的联系比较松散..更适合集成现有模块

混合模式

混合模式。。当我们在中国时说汉语，在日本说日语。但在大多数国家，我们可以说当地语言，也可以使用通用的英语来交流…

这就是混合模式..

一个大型系统更应该采用混合模式，来取长补短…

使用COOKIE/SESSON进行同步登录

当双方模块同一语言，运行在同一空间下时，使用COOKIE/SESSION交换TOKEN会大大的提升开发效率..A登录时调用B的API。设置COOKIE一类的。

使用数据库为中心进行TOKEN交换.

远程TOKEN交换

当双方为远程时，可以使用WEB接口进行TOKEN交换..

$sign=hash(uname+time+key)

b.jsp? (uname,time,sign)