单点登录系统

单点登录系统保存了用户的登录名和密码,上网用户在单点登录系统中认证成功后,就可以直接登录各个业务系统。

1. 用户使用单点登录系统的登录界面,输入用户名和密码登录成功后,
单点登录系统为用户浏览器安装一个cookie,cookie的值是一个全局唯
一的字符串 (下文称为ticket),理论上这个唯一值永远不能重复,用来
标识用户成功的登录请求。同一个用户,在同一个时刻登录两次,得到的
ticket值 应该完全不同。
2. 用户访问业务系统时,如果当前用户已经在业务系统中登录,那么访问
业务系统的cookie中,会携带单点登录ticket,业务系统根据此ticket,去
单点登录系统中查询用户是否在线,如果在,就允许继续访问,否则就执行
注销操作
3. 用户在任意一个业务系统中执行注销操作时,业务系统在拦截注销操作,
并且与单点登录系统联动,在单点登录系统中完成注销后,再跳转回业务系
统的注销界面

优点

1. 单点登录系统的整套拦截和转发流程,可以封装成为公共组件,代码修改量少
2. 所有业务系统都可以使用上述方案增加与单点登录系统的联动功能

缺点

上述单点登录功能,依赖浏览器的cookie功能,如果浏览器不支持cookie,将无法使用
关于这个方案的安全性问题,可以通过定期更新ticket值,或每次访问都生成不同的ticket值来进行规避。
因为涉及对于单点登录系统的大量访问,所以会使得单点登录系统成为瓶颈,我们项目中采用性能更高的网络协议,
例如UDP协议进行在线状态交互,因为UDP报文头部较小,报文有效内容比例大,同时报文长度短,比现有的HTTP协议性能高2个数量级,每秒支撑1000次查询请求,是没有问题的.

我们使用了JWT来做用户的状态保持机制和数据认证

因为JWT的token是保存在浏览器端的,不影响服务器开销,
多台服务器也可以使用,不需要多次登录,会保存在浏览器一
个空间里,这个空间加密性比cookie强,即使cookie被截获,
也不会泄露用户信息,比较安全.
JWT一般会采用消息认证机制:在哈希算法基础上混入秘钥,
防止哈希算法被破解, 避免签名被伪造,效率比较高.

JWT白名单

在用户完成修改密码操作时. 将该用户加入到白名单中,
先根据用户身份的唯一标识判断用户是否在白名单中,如
果在,说明用户在token有效期内已经修改过一次密码, 现
在就需要先删除用户白名单中的token数据,用户修改完密
码后, 需要让用户重新进行登录生成新的access_token返
回给客户端,调用生成token的工具生成access_token(访
问token)的数据,判断用户是否有对应的白名单,如果有则将
该token值存入到redis数据库的白名单中.
当用户登录成功后,再进行用户认证,在验证token成功后, 
对该用户的白名单进行验证,判断该用户是否在白名单中,
如果在,则验证token是否在白名单中,如果在则允许用户访问,
如果不在则不允许用户访问, 返回错误

 JWT黑名单

关于登录状态信息续签的问题。比如设置token的有效期为一个小时,
那么一个小时后,如果用户仍然在这个web应用上,这个时候当然不
能指望用户再登录一次。所以我们在每次用户发出请求的时候都返回
一个新的token,前端再用这个新的token来替代旧的,这样每一次请
求都会刷新token的有效期。但是这样,需要频繁的生成token。另外
一种方案是使用Js来动态续签。判断还有多久这个token会过期,在
token快要过期时,返回一个新的token。
用户主动注销,后台无法让用户强制下线。JWT并不支持用户主动退
出登录,当然,可以在客户端删除这个token,但在别处使用的token
仍然可以正常访问。为了支持注销和后台主动强制让用户下线, 我们在
项目中的方案是在注销时将该token加入黑名单。当用户发出请求后,
如果该token在黑名单中,则阻止用户的后续操作,返回Invalid token
错误。对于名单的维护可以使用redis,token的过期时间和redis中数
据的存活时间保持一致。
05-28 16:02