【SSO单点登录03】使用黑白名单机制解决JWT主动注销和防篡改

引言

本篇主要用黑白名单机制解决上篇文章遗留的JWT无法主动注销和防篡改问题

主动注销

上篇文章我们谈到用户退出登录后前端销毁保存在客户端中的token可能带来的token泄露问题，也就是登出之后token无法主动过期。其实，我们可以借助第三方的方式，如使用redis实现黑白名单的机制来让token过期

白名单机制

我们可以在用户登录后把生成的JWT存储到redis中，两者的过期时间保持一致（Redis存在JWT即不会过期），当用户退出登录时，即从redis中删除对应的token。前端发起请求时，需要判断JWT在redis中是否存在，不存在即登出。
但这种方式违背了JWT的初衷，带来了token一样的内存开销问题，因为用户登录的操作明显多于登出，增加了redis的负担，带来了更多的缓存。于是，我们可以反向行之，将退出用户的token放在redis中，即黑名单机制，从而释放更多的缓存。

黑名单机制

当用户退出登录时，从将token放置在redis中，用户每次发出请求只需验证token在不在redis中，若存在，则token是无效的。同时，存入redis的token有效期可以与token有效时间一致，从而释放更多缓存。

由于仅在用户退出登录时才将token放在redis中，给服务器带来的压力远小于白名单，大多数情况下，登录状态都是token自动过期，而不是用户主动退出登录(毕竟，谁会热衷于频繁的登录登出)

于是，使用黑名单机制可以很好的解决JWT主动注销的问题

如何防止token被篡改

前端将token保存在客户端中，很容易造成泄露，但由于JWT独特的特性，signature基于header和payload生成 即根据以下加密算法生成

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

由于secret由服务器保存，黑客无法根据header和payload生成正确有效的signature，当服务端进行验证时，会根据加密算法重新生成signature与前端传递过来的signature进行比较，如果不一致即说明被篡改，校验不通过

 JWT.require(Algorithm.HMAC256(SIGN)).build().verify(token);

会直接返回false 过滤器不通过直接返回401

所以secret需要妥善保管好，当泄露后黑客就可以直接修改了 Header 和 Payload 之后，重新生成一个 有效的Signature，从而导致JWT被篡改。所以，只有secret不被泄密，JWT就是安全的。

数字签名

主要针对JWT中的signature

• 前端将原文md5加密后，再用私钥对md5加密后的结果加密，变成一个sign，一并传给后端【用于校验】
• 后端收到后，用公钥解密，得到原文md5加密后的结果， 再对传过来的文章进行md5加密，判断两个md5的结果是否一致，若一致，则表明原文没有经过篡改

黑客不知道私钥，也就没法在篡改原文后生成跟原文对应的sign，从而无法通过验证

总结

本篇基于使用JWT进行用户认证和授权使用问题的改进，下篇介绍分布式session即springsession的使用