这是一个老话题了，当前各门户一般也都实现了多个业务之间的单点登录。下面根据 我经历过的项目，谈一下我自己的看法。
为什么需要单点登录：
产品刚上线时，一般由于用户量少，所有的功能都放在一起，一般也不需要具体的单 点登录。随着用户量和业务发展的需要，要求逐步将产品按功能或性能分为相应独立的站 点，并分开部署，这就需要在各个站点之间进行单点登录，以达到用户一次登录，就可以 使用多个站点。
单点登录的实现：
简单方法： 在同一个域内的站点，可以简单的通过共享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时 ，就可以直接通过算法来验证合法性，只有算法验证通过后，再进行下一步的操作。
以上只是从整体上描述统一认证的设计，中间还有很多细节没有描述出来，需要了解 的我们可进一步讨论。
下一篇，准备写一下认证中心内部，如何实现分布式认证系统，支持高并发、防攻击 等方面内容。