先说jwt
JWT全称（Json web token），也就是说 本质上它就是个Token，我觉得这一点很重要。采用json的实现，能有效的避开各种浏览器、运行环境的限制，而达到为用户创建身份认证的凭证，并且是跨语言的。

所以jwt本质是提供一个token的实现方式，一个基本的规范；而不是token之外的其他思路。密钥掌握在后台，所以jwt可以在后台运算，后台验证；又因为后台可以运算验证，所以可以不需要存储轻量的完成整个验证的逻辑。有得就有失，运算只能知道这个token是不是符合密钥和规范的约束，可以得出一个token运算的正确性，而不能确定输入token的有效性。一旦生成就不能收回，也无法刷新…

第一段加密方式.第二段携带内容.第三段对前面的加密结果

所以单纯的JWT好用，但是使用限制带了适用范围的限制。
jwt目前为止，好多年了，都停留在0.7.0的版本，我想就是和这个有一些关系。如果能巧妙的解决token刷新的问题，1.0.0我相信马上就来了。

再说jwt+redis
redis直白的说就是一句话：一个持久化工具。因为redis允许数据设置失效时间，配合jwt使用时，可以方便的解决token刷新的问题。
jwt的设计初衷包含减轻对外部存储的依赖，减少了分布式组件的依赖，减少了硬件的资源，现在又要拉上redis，在一定程度上又背离了这一设计初衷。

所以我觉得，jwt和redis搭档之后，jwt最大的意义就成了一个token操作工具，本身的时效方面验证基本失去了意义。当然一定要承认jwt是一个相当不错的“轮子”，直接使用是非常便捷的。当系统又特殊的设计需要，jwt不能满足时，自己造个其他token的轮子也是有必要且有意义的。

所以我觉得使用jwt和redis的组合时，不必过分纠结这样是否违背jwt的设计初衷，我们更多的是需要jwt的token操作功能。