spring cloud实战与思考（四） JWT之Token主动失效

需求：

JWT泄露、密码重置等场景下，需要将未过期但是已经不安全的JWT主动失效。

本文不再复述JWT的基础知识，不了解的小伙伴可以自行Google一下。这里主要是针对以上需求聊一聊解决方案。如果服务端发给客户端的JWT还在有效期内，但是变得不安全，服务端需要及时将这些JWT标识出来并作废掉。相较于session机制，服务端对JWT的控制要弱很多。JWT一旦签发，就脱离了服务端的掌控。通常情况下，服务端只能通过设置JWT的过期时间“exp”声明，使得JWT在过期后被动失效。

正所谓鱼与熊掌不可兼得。在我们享受JWT便利性的同时，也要设计复杂点的机制来弥补服务器对JWT控制能力弱的缺点。网上有人建议服务器将签发的JWT都存一份到分布式缓存中，这样JWT就能被跟踪和标识。这种方式虽然解决了问题，但是每个JWT都保存起来，每次校验都做查询的方式同分布式session几乎无分别。这相当于放弃了JWT占用服务器空间小、有效性校验速度快的优点。在没有跨域资源访问的需求场景下，分布式session的方案反而更有优势，至少可以在session中保存敏感信息，而不用担心在客户端被泄露。

下面讲一下我在当前项目中使用的JWT控制方案：

　　1. 每个JWT必须设置过期时间，并且该时间不要设置的过长。

　　2. 在用户登陆表中，为每个用户分配一个“token_group_id”字段。该字段保存一个随机字符串。

　　　　

　　3. 在JWT的payload中增加“groupId”声明。签发JWT的时候，将用户对应的“token_group_id”字符串写入该声明。

　　　　{

　　　　　　"exp": 1525256018000,

　　　　　　"groupId": "jeJ4IVpR17z68Q0cTr53gQ25e588P653"

　　　　}

　　4. 在服务端的分布式缓存上保存一个“groupId”黑名单列表。如果用户的JWT泄露或者重置密码等需要作废已经签发给用户的JWT时，为该用户生成一个新的“token_group_id”存入用户登陆表。将原有的“token_group_id”加入黑名单。

　　5. “token_group_id”在黑名单中的保存时间是JWT的过期时间。过期后“token_group_id”自动从黑名单中删除。

　　6. 所有需要做JWT有效性校验的服务器启动时访问分布式缓存将黑名单下载到本地内存。并且订阅分布式缓存的消息推送功能，在黑名单发生增删的时候，接收推送消息同步修改内存中的黑名单列表。

　　7. 服务器做JWT校验的时候，除了校验过期时间，还要查询内存中的黑名单列表。若JWT的“groupId”在黑名单中，则判定该JWT为失效。

讨论：

　　1. 你这个方案也用到了分布式缓存，也要在缓存中保存数据。这和分布式session或者保存所有的JWT的方案性质不是一样的吗？

　　　　形式上虽然相同，但是保存数据的数量级差别很大。其它两种方案需要保存当前活动用户的全集，而本方案只保存不安全的JWT。相信通常情况下出现token泄露和密码重置的频率是比较低的。需要撤销的JWT占整个活动用户的百分比很小。

　　　　此外JWT只在黑名单中保存一个过期周期，此后就会被删除，进一步控制了黑名单的增长。这样黑名单就可以装载到服务器的内存中，协助完成JWT的本地校验。而无需每次校验时要访问远端服务。

　　2. 为什么多此一举的新增一个“groupId”，直接将需要作废的JWT放到黑名单中不就行了吗？

　　　　1） JWT本身比较长，使用较短的“groupId”可以加快黑名单的查询速度。

　　　　2） 若系统不限制用户同一时间能申请的JWT数量。那么可能遇到用户在短时间内恶意请求大量Token的情况。这些Token都放到黑名单中会导致黑名单数量迅速膨胀。使用“groupId”则可以避免这种不可控情况。

　　3. 你这个方案又要分布式缓存，又要做黑名单的实时同步。整个方案实施的复杂性似乎超过了分布式session，用它代替分布式session会不会得不偿失？

　　　　1）在一个稍具规模的分布式系统中，分布式缓存、系统总线都是必备的组件。利用这些现有组件可以设计多种方案做数据同步。所以方案看似复杂，实现起来还是不难的。

　　　　2）每个系统侧重的性能指标各有不同。本方案的JWT校验的计算和查询都是在本地内存中完成，不需要依赖远端服务。能够缩短请求的响应时间。对于强调低延迟响应的系统还是比较合适的。