jwt属于无状态设计，用户登陆的信息关键存放在jwt加密数据里，这种设计下服务器不需要存储jwt密文，只需要解密就能拿到授权信息等用户信息。这种设计是一种利用计算力减少token设计下数据库及缓存的压力和设计复杂度，因此它的本质就是不存储登陆授权，而通过密文本身保存授权信息。

token加redis设计，是一种登陆后分配随机token，然后记录token与用户信息对应关系的设计。

很明显，这两张设计的区别就在于token实际上是需要服务器存储，每次验权需要查询数据库。jwt不需要服务器存储，信息本身就存储于jwt本身，这种模式无需使用数据库。

但是这种流行的jwt有一个设计上的缺陷，他通过密文传输用户信息，那么服务器在这种基础结构下是无法做到关闭用户登陆授权的操作，如果用户的jwt密文被偷窃，那么黑客就能以用户身份登陆，并且即使知道密文丢失，也无法关闭被偷窃的jwt密文。为了应对这一问题，可以使用jwt内部验证有效期和jwt黑名单模式，但是有效期始终无法做到及时停止jwt授权，这是一个治标不治本的方法。而jwt黑名单模式，则需要数据库或内存存储黑名单，那么，这实际上违背了jwt的免数据库设计原则。

因此，如果严格按照两种模式设计，jwt更适合低安全级别的服务器设计，如普通的博客、阅读器等等，这种服务允许不严格的登陆授权，即使密文丢失也不会造成用户的严重损失，却能获得较高的服务性能。

token模式，必须配合数据库进行存储和查询，因此性能较低，但token模式却能做到及时的授权关闭，已经登陆授权可见可查，每一次token都会有对应的记录。因此token模式适合较高安全度和用户登陆等信息分析的系统，如政府系统，支付系统等不可能允许高权限的token被偷窃却不能及时关闭授权。

jwt，适合轻量的系统和权限不严格系统。

token，适合重量系统和权限有严格要求的系统。

谢谢大家的阅读和头条的推荐，我再来详细的和大家讨论下这两者在实现上的区别，这样大家可能更方便的理解这两个不同的概念。

我们讨论的这两种方式只限于规范实现，如果有其他优化或者衍生设计模式则不在讨论之内。

token：

普通的token方式采用的是：登录-->生成随机字符串（token）-->服务器保存token与用户信息的对应关系

对应用户利用token校验的流程是 token-->查询token对应用户信息-->各系统根据用户信息进行业务处理。

很明显可以看出，token模式下的字符串实际上不需要和用户信息有任何关联，生成的token字符串的要求就是唯一，不能被其他用户占有，否则就会出现用户登录后实际上是以其他人身份进行业务处理。如果字符串是随机生成，那么黑客就无法猜测token的生成规律，也无法从token直接猜测到用户相关信息。

jwt:

jwt采用的生成：登录-->生成带有用户数据的加密字符串（该字符串服务器并不存储，直接下发给客户端）

校验：客户端将存储的jwt密文带上-->服务器解密密文，获取到用户信息

可以看出，jwt的凭证不仅要求唯一，还要求密文本身实际上是带有了用户信息，当然这块可以是非敏感信息，这只是实现上的细节区别，和结构本身没有特别大的关联。服务器本身并没有存储这次jwt密文，每次服务器的处理都是直接解密jwt密文。这样做的好处就是服务架构内直接抛弃了登录相关的传统token系统，并且服务器不再管理登录状态，token有效状态等问题。

而jwt带来的问题，凭证实际上的一串密文，更多的用户信息或session信息需要更大的密文来存储，进而每次请求都带上jwt就会使网络传输的内容变大，加大了网络开销；凭证是一串密文，那么如果黑客破解了服务器的加密方式，那么密文实际上就是用户信息在网络上传输，黑客可以直接伪造jwt登录或通过jwt密文获取到用户信息；jwt本身不管理jwt的有效性，一旦密文被偷窃，无法做到关闭掉黑客的授权。

谢邀。

什么是JWT

JWT（Json Web Token），是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准。由头部（Header）、负载（Payload）、签名（Signature）三部分构成，其中每一部分使用Base64编码处理。

Header 中存储了所使用的加密算法和 Token 类型。

Payload是负载，JWT 规范规定了一些字段，并推荐使用，当然每一个开发者也可以自己指定字段和内容。需要注意的是，该部分内容只经过了 Base64 编码，相当于明文存储，所以不要放置敏感信息。

而Signature，则是使用Base64编码后的Header 和Payload以及一个秘钥，使用header中指定签名算法进行签名。

可用下面的图对上述概念进行总结：

JWT的优点&问题

JWT属于无状态，不依赖Cookie，可以在禁用Cookie的浏览器中运行，可有效防止CSRF攻击；服务端不用存储session，易于扩展；相比XML更加简洁，更加适合在HTTP环境中传输。

那么JWT都存在哪些问题呢？主要集中在以下几个方面

• 无法作废已颁布的Token，比如说用户注销这个功能，传统的基于session的方案，只需在服务端删除该session即可，因为状态在服务端存储。而JWT就比较难办到，因为JWT是无状态的，存储在客户端，即使被删除了，一定有效期内服务端并不知道，它仍然是有效的。

• 无法应对过期的数据

• 安全机制不够高

JWT适用场景

• Restful API无状态验证

• 一次性验证：比如用户注册某网站后需要发送一封邮件让其激活账户，通常该邮件中包含一个链接，该链接往往含有以下几个特点：能够标识唯一用户、不能被篡改、具有时效性。

Redis & Token

自己生成一个32位的key，value为用户信息，客户端访问时服务端首先判断Redis里是否有该Token，如果有，则加载该用户信息完成登录。服务需要存储下发的每个token及对应的value，维持其过期时间。

本文为作者“一个程序员的奋斗史”悟空问答原创文章，未经允许转载、抄袭必究！

很高兴能回答你的问题，这里我说下我对jwt、redis还有token的理解，可能和楼主理解的有不一样的地方。

redis

redis是一种常用的缓存技术，是一种非关系型数据库，常见类型包括 字符串(String)、哈希(Hash)、列表(list)、集合(sets)和有序集合(sorted sets)，在APP服务端的接口中，并不充当检验用户唯一性的标准，更多的是处于mysql数据库之前的一种数据处理。

jwt

jwt和token用于判断用户是否登录，我们在开发当中经常就把加密后的jwt等同于token，APP在请求登录接口时返回token，在个人中心等需要判断用户身份的接口中将返回的token值传递给服务器端进行验证。

jwt的具体使用就不在这里做过多的介绍，简单说一下操作过程

服务器通过jwt的加密方式生成一串字符串，在请求接口中返回给客户端，客户端在所需接口中将token传递给服务器，服务器再进行解密，并进行一系列逻辑操作。核心过程可以理解为加密和解密的过程，如果传递过来的字符串解密失败，那么可以返回用户信息不存在者登录已过期

token

token在上边也介绍了，其功能是验证用户是否已登录，然后返回用户相应的信息。

token的生成显得就很随意了，你可以md5加密字符串，拼接时间戳，加盐，总之token的生成规则由开发者自己来定，并无固定的生成规则，只要给到客户端，然后再又客户端传递后进行校验。

希望我的问题能帮助到你。

以下内容纯手打：jwt 是json web token 的缩写，所以简单讲jwt只是token的一个标准实现，至于为什么要把redis和token结合起来用，是因为token仅存储于客户端，相对于服务端是无状态的，服务端通过标准的解密，实现对token的验证以及获取必要的payload。此时如果需要方便的对客户端进行强制下线或者实现单客户端登录则需要知道当前已经连接了多少客户端，有多少可用的token，这里就借助了redis存储，同时token在服务端也就变成了有状态了，所以请根据具体的使用场景决定是否配合redis等数据库工具

首先，app端，服务端，是一种典型的前后端分离的数据交换架构。前端（app）通过token从后端服务取数据，后端通过校验token，判断是否给前端（app）返回数据。楼主对jwt的认知不对，下边对这两种进行下说明。

jwt本身就是一个token，token的一种实现不过这个token自带一些用户权限信息。本身是一种无状态的设计概念，后端加密解密判断jwt本身是否过期有效，后端不存储任何跟token存储有关的东西，只有一套加密生成，解密校验的程序。

redis和token，redis是一个缓存数据库，可以存档token，可以设置过期时间。楼主所理解的应该是服务端通过redis存储token，然后前端app带着token进行访问的时候，服务端从redis中取token用来校验，如果过期说明token失效，也可能是伪造token。

最后，两者可以结合使用。

jwt是生成和校验解密token的工具，redis是缓存，他们之间并不冲突，加起来一起用效果更好，仅仅用token是不够的，因为一但设置token意味着其登录过期时间也就确定了。就无法让其在有效期内失效，这样不合理的。。所以可以通过redis记录token，控制其的有效性，和记录一些信息。所以 token加redis才是正确的选择。

都可以，通常情况下正式点我会用shiro+redis实现权限session认证管理，免去了自己实现session认证的过程，并且它还提供了一些进阶的功能。简陋点的话，redis+token就可以了，要自己去设计实现，通常配合拦截器实现session认证。

就个人的理解而言，各自有其优缺点，并且针对不同的场景需要进行约束性开发。

Token机制简述

Token的用途

用户在登录APP时，APP端会发送加密的用户名和密码到服务器，服务器验证用户名和密码，如果验证成功，就会生成相应位数的字符产作为token存储到服务器中，并且将该token返回给APP端。

以后APP再次请求时，凡是需要验证的地方都要带上该token，然后服务器端验证token，成功返回所需要的结果，失败返回错误信息，让用户重新登录。其中，服务器上会给token设置一个有效期，每次APP请求的时候都验证token和有效期。

token+redis机制

token + redis机制是中心化的，每次验证token有效性时，都需要访问redis，其核心优点实服务端可以主动让token失效，缺点是每次都要进行redis查询。占用redis存储空间。

jwt机制

这是一种无状态身份验证机制，因为用户状态永远不会保存在服务器内存中。服务器受保护的路由将在授权头中检查有效的JWT，如果存在，则允许用户访问受保护的资源。由于JWT是独立的，所有必要的信息都在那里，减少了多次查询数据库的需求。

用户发起登录请求，验证通过后，服务端创建一个加密后的JWT信息，作为Token返回。在后续请求中JWT信息作为请求头，发给服务端。服务端拿到JWT之后进行解密，正确解密表示此次请求合法，验证通过；解密失败说明Token无效或者已过期。

jwt的优点主要有：

1.t是去中心化的，便于分布式系统使用；

2. 基本信息可以直接放在token中。user_id，session_id；

3. 功能权限信息可以直接放在token中。用bit位表示用户所具有的功能权限。其缺点有：服务端无法主动让token失效，另一个是无法很好地控制payload的数据量。

小结

jwt和token+redis两种方案，没有最优，只有结合不同的业务场景，寻求最适合的方案。

问题很不专业，jwt本质上就是token，另外关redis什么事情？完全不是一类好吗？同时使用jwt和redis的都很多

Jwt是带有签名的客户身份令牌。安全性还是比较高的。但是需要正确使用。它本身主要是证明客户身份，并不包含机密信息。如果需要避免重复使用，可以提供时间戳，可以一次性使用。这样很多安全问题就都解决了。现在很多服务都使用jwt认证。