单点登录系统
单点登录系统保存了用户的登录名和密码，上网用户在单点登录系统中认证成功后，就可以直接登录各个业务系统。
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中数
据的存活时间保持一致。