单点登录系统

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

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中数

据的存活时间保持一致。