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