基于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刷新机制