摘要：
JWT不支持用户主动注销。当然，您可以删除客户端上的令牌，但其他地方使用的令牌仍然可以正常访问。为了支持注销并在后台主动强制用户脱机，我们在项目中的解决方案是在注销时将令牌添加到黑名单中。用户发送请求后，如果令牌在黑名单中，则会阻止用户的后续操作，并返回Invalidtoken错误。Redis可用于维护列表。令牌的过期时间与Redis中数据的生存时间一致。
单点登录系统
单点登录系统保存了用户的登录名和密码，上网用户在单点登录系统中认证成功后，就可以直接登录各个业务系统。
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中数
据的存活时间保持一致。