基于redis的认证方式分析

redis解决短信验证码时效性，以及使用token的方式判断是否登录的问题。(没用jwt)
这里面使用两个拦截器的方式解决：1. 给token有效期刷新 2.判断用户是否已登录

目前验证用户是否已登录，仍然是用到redis和服务端程序去判断，这个和使用session的判断方式有点相似，因为也会用到服务端资源。
但是token与session还是有非常大的不同，认证通过后，(认证信息)session都是保存在内存中（服务端服务器中）占内存，如果是分布式的架构，那么也会影响性能。

而对于token的方式，认证通过后，(认证信息)token都是保存在redis中的，即使是分布式系统，对于该token都能拿到。也就实现了单点登录 就是在多个系统中，用户只需一次登录，各个系统即可感知该用户已经登录。
且能控制用户登录状态的。

jwt分析

头部，载体，签名
服务端根据秘钥信息，生成jwt(token)，将token作为数据返回，然后用户每次请求过来都在请求头携带该token。
如果用户携带token过来，服务端会用秘钥去解析该token，看是否通过。如果通过则代表该用户已登录。

key-value : token-userInfo 存入redis中
可以控制该token的有效期(也就是用户登录的有效期)，且能够将用户的一些信息保存到redis中

用户请求到达服务端，服务端根据秘钥再签发一个jwt(token)，与用户携带的token作比较，如果一致，则再去操作redis

security认证授权分析

认证流程：
调用框架方法，重写登录认证逻辑，JWT的载体可以存东西
将token返回给用户，让他每次访问都携带过来。
而解析token能得到它里面的载体，包含key的信息，能根据这个条件去redis中查找用户是否已经登录已经他的权限信息。
要让用户注销，那么就删除redis中的对应k-v，那么如果它再想请求需要登录才能访问的接口，会被jwt拦截器给拦截住。
每次用户访问需要登录才能访问的接口时，都会走jwt拦截器这么一个流程。

网上看到的解决方案，就是将权限信息也放在jwt的载体中，而不是redis的v中。这样符合逻辑吗？
答：不行。1.此时的放redis中起到一个单点登录，且能做登录超时下线的功能，能够控制用户的状态。只使用jwt的话，是无法控制用户登录状态的。

如果需要给这个方案加一个token刷新机制呢？
加一个过滤器，拦截所有请求，且在jwt过滤器之前执行。实质上就是刷新该用户对应于redis中的key。
如果请求头中没有携带token => 直接放行
如果携带了 => 那么jwt解析token => 去redis中操作 => 判断该key是否过期
=> 是，放行
=>否，更新token有效期

再次回顾了security的知识，三更的那个jwt过滤器是必要的，这种方式和session的方式还是具有区别。

  1. 对于session的方式，(认证信息)session都是保存在内存中（服务端服务器中）占内存
  2. 对于token的方式，认证通过后，(认证信息)token都是保存在redis中的
  3. 且重新整合加入了token刷新机制