jwt与token+redis，哪种方案更好用？

1问题描述

jwt与token+redis，哪种方案更好用？

问题结论

刚好最近有项目使用了jwt，而且是定制化的jwt的认证机制，就个人的理解而言，各自有其优缺点，并且针对不同的场景需要进行约束性开发，如用户剔除、同一用户每2h只生成一次jwt等。

2Token机制简述

21Token的用途

用户在登录APP时，APP端会发送加密的用户名和密码到服务器，服务器验证用户名和密码，如果验证成功，就会生成相应位数的字符产作为token存储到服务器中，并且将该token返回给APP端。以后APP再次请求时，凡是需要验证的地方都要带上该token，然后服务器端验证token，成功返回所需要的结果，失败返回错误信息，让用户重新登录。其中，服务器上会给token设置一个有效期，每次APP请求的时候都验证token和有效期。

在存储的时候把token进行对称加密存储，用到的时候再解密。文章最开始提到的签名sign：将请求URL、时间戳、token三者合并，通过算法进行加密处理。

22token+redis机制

用户验证通过后，服务端通过如uuid相关的方法，生成token，存储用户信息。当请求服务时，客户端将token带上来，进行查询验证，如token存在并在有限期内，请求有效，否则请求非法。

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

23jwt机制

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

Javajwt普遍选用java-jwt工具包依赖，gradle依赖：compile'comauth0:java-jwt:320'用户发起登录请求，验证通过后，服务端创建一个加密后的JWT信息，作为Token返回。在后续请求中JWT信息作为请求头，发给服务端。服务端拿到JWT之后进行解密，正确解密表示此次请求合法，验证通过；解密失败说明Token无效或者已过期。

jwt的有点主要有：a其是去中心化的，便于分布式系统使用；2基本信息可以直接放在token中。user_id，session_id；3功能权限信息可以直接放在token中。用bit位表示用户所具有的功能权限。其缺点有：服务端无法主动让token失效，另一个是无法很好的控制payload的数据量。

3小结

jwt和token+redis两种方案，没有最优，只有结合不同的业务场景，需求最适合的方案。就比如token2h过期，同一用户每15h只生成一次token，当两次token并存时，同时有效。大家可以考虑在这两种方案的前提下，分别如何实现？

网上关于移动客户端与服务器数据传输之间的 token 的细节使用好像都没有详细的说明，基本都是一笔带过。对于简简单单的加入一个固定的参数 token，其实是很容易被抓包的。

下面说一下我自己的方案：

云南移动机顶盒获取token失败可能是由于以下原因：
1 网络连接问题：请确保您的机顶盒已经正确连接到网络，并且可以正常访问互联网。如果存在网络故障或者防火墙等限制，可能会导致无法获取Token。
2 服务器异常：如果移动服务器出现了故障或者维护升级等情况，也有可能导致Token获取失败。您可以尝试稍后再次尝试。
3 设备配置错误：在一些特殊情况下，设备的配置信息不完整或者不正确也会影响Token的获取。例如，在使用第三方应用程序时需要输入相关参数和密钥等信息，请确认这些信息是否填写正确。
4 身份验证问题：某些服务提供商要求用户进行身份验证才能够获得Token，如果您没有通过身份验证，则无法获得有效的令牌。请根据具体提示进行 *** 作并重新尝试。
5 其他未知原因：在一些极端情况下，还有可能出现其他未知原因导致Token获取失败。此时建议联系相关技术支持人员寻求帮助解决问题。
总之，在处理涉及重要信息和资料时，请谨慎 *** 作以免造成不必要的风险和损失。

前言

一天，你有个需求，你要去超市买一瓶可乐。 到了超市买了可乐，你告诉售货员，下次给我准备下雷碧，我下次来拿。 第二次，你去超市拿雷碧，售货员说他不记得你什么时候说要准备雷碧。 这次你学聪明了，售货员给你写了个纸条，上面有超市的章印，下次你带着纸条来，买上了超市 给你准备的雷碧

cookie 是一个非常具体的东西，指的就是浏览器里面能永久存储的一种数据。跟服务器没啥关系，仅仅是浏览器实现的一种数据存储功能。

cookie由服务器生成，发送给浏览器，浏览器把cookie以KV形式存储到某个目录下的文本文件中，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间。所以每个域的cookie数量是有限制的。

不管你是请求一个资源文件(如html/js/css/), 还是发送一个ajax请求, 服务端都会返回response而response header中有一项叫set-cookie, 是服务端专门用来设置cookie的;

HTML5提供了两种本地存储的方式 sessionStorage 和 localStorage；

在上面我们了解了什么是Cookie，既然浏览器已经通过Cookie实现了有状态这一需求，那么为什么又来了一个Session呢？这里我们想象一下，如果将账户的一些信息都存入Cookie中的话，一旦信息被拦截，那么我们所有的账户信息都会丢失掉。所以就出现了Session，在一次会话中将重要信息保存在Session中，浏览器只记录SessionId一个SessionId对应一次会话请求。

这里我们写一个新的方法来测试Session是如何产生的，我们在请求参数中加上>