JWT与token+redis对比
16、JWT与token+redis对比分析一、使用Token+redis的好处?1.性能问题。JWT方式将用户状态分散到了客户端中,相比于session,可以明显减轻服务端的内存压力。Session方式存储用户id的最大弊病在于Session是存储在服务器端的,所以需要占用大量服务器内存,对于较大型应用而言可能还要保存许多的状态,一般还需借助nosql和缓存机制来实现session的存储,如果是
JWT与token+redis对比
分析一、使用Token+redis的好处?
- 性能问题。
JWT方式将用户状态分散到了客户端中,相比于session,可以明显减轻服务端的内存压力。Session方式存储用户id的最大弊病在于Session是存储在服务器端的,所以需要占用大量服务器内存,对于较大型应用而言可能还要保存许多的状态,一般还需借助nosql和缓存机制来实现session的存储,如果是分布式应用还需session共享。
- 单点登录。
JWT能轻松的实现单点登录,因为用户的状态已经被传送到了客户端。token 可保存自定义信息,如用户基本信息,web服务器用key去解析token,就获取到请求用户的信息了。我们也可以配置它以便包含用户拥有的任何权限。这意味着每个服务不需要与授权服务交互才能授权用户。
- 前后端分离。
以前的传统模式下,后台对应的客户端就是浏览器,就可以使用session+cookies的方式实现登录,但是在前后分离的情况下,后端只负责通过暴露的RestApi提供数据,而页面的渲染、路由都由前端完成。因为rest是无状态的,因此也就不会有session记录到服务器端。
- 兼容性。
支持移动设备,支持跨程序调用,Cookie 是不允许垮域访问的,而 Token 则不存在这个问题。
- 可拓展性。
jwt是无状态的,特别适用于分布式站点的单点登录(SSO)场景。比如有3台机器(A、B、C)组成服务器集群,若session存在机器A上,session只能保存在其中一台服务器,此时你便不能访问机器B、C,因为B、C上没有存放该Session,而使用token就能够验证用户请求合法性,并且我再加几台机器也没事,所以可拓展性好。
- 安全性。因为有签名,所以JWT可以防止被篡改。
分析二、JSON Web Token+redis方案说明
JWT是基于token的身份认证的方案。json web token全称。可以保证安全传输的前提下传送一些基本的信息,以减轻对外部存储的依赖,减少了分布式组件的依赖,减少了硬件的资源。可实现无状态、分布式的Web应用授权,jwt的安全特性保证了token的不可伪造和不可篡改。本质上是一个独立的身份验证令牌,可以包含用户标识、用户角色和权限等信息,以及您可以存储任何其他信息(自包含)。任何人都可以轻松读取和解析,并使用密钥来验证真实性。这时候又凸显出了传统Session模型的好处,服务器生成令牌下发给前端,前端只持有令牌本身,而令牌代表的数据则完全由服务器说了算,此种模式下:什么Session会话、踢人下线之类的都是信手拈来,但是缺点又回来了:失去了去中心化,水平扩展比较难,且服务器需要维护所有用户的数据状态,性能压力比较大常见解决方案也很简单,那就是把会话数据放到专业的数据中心,比如Redis, 此模式既保证了服务器对会话数据的可控性,又保证了服务水平扩展时的会话一致性
缺陷:
1)JWT在生成token的时候支持失效时间,但是支持的失效时间是固定的,比如说一天。但是用户在等出的时候是随机触发的,那么我们jwt token来做这个失效是不可行的,因为jwt在初始化的时候已经定死在什么时候过期了。采用其他方案,在redis中存储token,设置token的过期时间,每次鉴权的时候都会去延长时间
2)jwt不适合存放大量信息,信息越多token越长JWT就是一个字符串,经过加密处理与校验处理的字符串
分析三.jwt+redis的登录方案流程:
前端服务器收到用户登录请求,传给后台API网关。API网关把请求分发到用户服务里进行身份验证。后台用户服务验证通过,然后从账号信息抽取出userName、login_time等基本信息组成payload,进而组装一个JWT,把JWT放入redis(因为退出的时候无法使jwt立即作废,所以使用保存在redis中,退出的时候delete掉就可以了,鉴权的时候加一层判断jwt是否在redis里,如果不在则证明jwt已过期作废),然后包装cookie中返回到前端服务器,这就登录成功了。前端服务器拿到JWT,进行存储(可以存储在缓存中,也可以存储在数据库中,如果是浏览器,可以存储在 localStorage 中,我实现的是放入到cookie里面)登录后,再访问其他微服务的时候,前端会携带jwt访问后台,后台校验 JWT,验签通过后,返回相应资源和数据就可以了。
建议
如果项目并不大,JWT是个好选择,天然的去中心化模式,会话状态由令牌本身自解释,简单粗暴但是缺点页很明显,如题所示,一旦下发便不受服务端控制,如果发生token泄露,服务器也只能任其蹂躏,在其未过期期间不能有任何措施对此模式践行比较完善的框架推荐你了解一下token+redis,此框架扩展了token-session模型,将会话数据放在了Redis下,并提供了多种Session序列化方案,诸如注销登录、权限认证、踢人下线等常见功能全部一行代码就可以完成
更多推荐
所有评论(0)