多站点单点登录(SSO)设计

这是一个老话题了，当前各门户一般也都实现了多个业务之间的单点登录。下面根据我经历过的项目，谈一下我自己的看法。

　　为什么需要单点登录：

　　产品刚上线时，一般由于用户量少，所有的功能都放在一起，一般也不需要具体的单点登录。随着用户量和业务发展的需要，要求逐步将产品按功能或性能分为相应独立的站点，并分开部署，这就需要在各个站点之间进行单点登录，以达到用户一次登录，就可以使用多个站点。

　　单点登录的实现：

　　简单方法： 在同一个域内的站点，可以简单的通过共享Cookie（将登录用户名存放Cookie中）来实现单点登录。这种方法实现简单，安全性方法可以通过将Cookie值加密方式加强，但对不同域下及不同开发语言下（如A站点C#，B站点C）实现麻烦。

　　推荐方法：建立统一的认证中心，认证中心提供：

　　1、用户登录认证（认证用户名和密码），如果成功，返回表示本次登录的登录Token

　　2、登录Token认证（认证Token是否正确），如果成功，返回当前登录的用户名

　　3、延长Token有效期

　　4、退出（使Token失效)

　　认证中心独立于各个站点，单点流程一般场景如下：

　　1、用户在站点A输入用户名和密码点击登录

　　2、站点A将用户名和密码转发给认证中心进行认证，认证中心返回Token

　　3、站点A将当前登录用户和Token存入Session（或Cookie)

　　4、在站点A上点击连接访问站点B，通过URL参数方式，将Token带给站点B

　　5、站点B将Token转交到认证中心，认证正确，返回当前用户名。

　　6、站点B将当前登录用户和Token存入Session(或Cookie)，完成登录流程

　　这样的设计下的Token，还可以用在异步使用Ajax去访问服务器端的接口（接口可能独立部署在不同的站点下），这样只需要带上Token，服务器端的接口认证Token通过后，直接返回这个登录用户的相应用户信息。

　　安全性考虑：

　　1、用户登录认证接口，可增加认证频率、认证IP等限制，防止暴力攻击

　　2、Token其实就是一串表示本次登录的唯一字符串，可以生成字符串时，增加摘要信息。如Token的组成为：A+MD5(A+PWD) 的方式，A为随机生成的GUID，这样在验证Token时，就可以直接通过算法来验证合法性，只有算法验证通过后，再进行下一步的操作。

　　以上只是从整体上描述统一认证的设计，中间还有很多细节没有描述出来，需要了解的我们可进一步讨论