Redis+Session,Cookie+Session,JWT详细解析

写在前面：本文介绍了JWT、Reids+Sesion、Cookie+Session的区别、优缺点、以及运行流程。

Cookie+Session,Redis+Session,JWT三者的区别

一、基于Cookie+session的认证机制

认证流程

• http是无状态协议，客户端发送一个请求提交，当用户关闭页面后，信息不会保留，下次请求还需重新提交。
  • 因为http协议不知道是哪个用户发送的请求，所以只能在服务器上存储一份用户的信息(session),这份登录信息会在服务器响应的时候发送一个(sessionIonid)保存到cookie中，下次客户端发送请求的时候把这个sessionid带上放到cookie中带给服务器，就可以服务器识别出我们请求来自于哪个用户，
• 缺点
  • 服务器开销大，每次访问已请求都会创建一个session，当用户数量过多，服务器就会存在大量用户session。
  • 当用户认证后，session对象还保存在服务器内存中，意味着用户下次再访问的时候必须要在这台服务器上，那如果客户端第一次认证在服务器A得到了session，但第二次session被分配到了服务器B，就导致session失效，不能实现单点登录。
  • 因为sessionid是放在cookie中的，如果cookie被截获，用户就很容易受到跨站域请求伪造攻击（CSRF）
• 特点：用服务器存储session的空间花费，缩短认证的时间，空间换时间。

二、基于Redis+Token的认证机制

认证流程

• 客户端登录，输入手机号和密码，后台进行验证，如果没有这个手机号没被注册，则自动根据手机号创建新的用户。如果有，那么就生成token，拿token和加固定前缀生成rediskey，value为用户信息，以hashmap方式存入redis。并设置token有效期
• 前端会带着这个Token到服务器中，服务器拿到之后去跟redis中的key比对，并检查过期时间。之后就是用户去做一系列操作。
• 优点：其核心有点是服务端可以主动让token失效。
• 缺点：Token+redis是中心化的，要能识别token必须能访问该reids，要求每次token都实时检测；占用redis存储空间
• 每次都要查询完redis返回的用户信息后，还要去数据库中查询想要的信息，增大了服务器的压力。

三、基于JWT的认证机制

认证流程

• 前端通过表单提交将用户和密码发送到后端接口。

• 后端校验通过以后，将用户的id等不敏感的信息作为jwt的payload,将其和Header分别尽心Base64编码拼接后，进行Singnatru,形成一个JWT(Token)。

• 后端把JWT字符串作为登录成功的结果返回给前端，前端可以将返回的结果保存在本地缓存中，退出时前端删除掉jwt即可。

• 前端可以每次请求的时候吧jwt放到http header的authorization中解决(Xss/XSRF攻击问题)

• 后端检查前端发送的JWT是否存在（检查签名是否正确、token是否过期等）

• 验证成功后，在取payload出里面的信息（如username),在使用该信息直接查询用户需要的后续逻辑。

• JWT的优点：

  • 可扩展性好，应用程序分布式部署的情况下，session需要做数据共享，通常可以存在数据库或者redis里面，而jwt不需要，无状态，jwt不在服务端存储任何状态。

• JWT缺点：

  • 安全性，由于jwt的payload是使用abse64编码的，并没有加密，因此jwt中不能存储敏感数据，而session的信息是存在服务端的，相对来说更安全。

• 性能：jwt太长，由于是无状态使用JWt，所有的数据都被放到jwt里，如果还要进行一些数据交换，那载荷会更待，经过编码之后导致jwt非常长，cookie的限制大小是4k，有可能放不下，所以jwt一般放在本地缓存里，并且用户每次请求都会携带jwt在header里，导致header可能比body还要打，而sesionid只是很短的一串字符，因此使用jwt的请求比session的开销大得多。

• 一次性

  • 无状态是jwt的特点，但也导致了这个问题，jwt是一次性的，想要修改里面的内容，就必须签发一个新的jwt。

对于文章中出现的任何错误请大家批评指出，一定及时修改。 有任何想要讨论和学习的问题可联系我：
邮箱：577371067@qq.com
不足之处请大家指正。