欢迎关注头条号:老顾聊技术
精品原创技术分享,知识的组装工
目录
前言JWT是什么JWT资料结构HeaderPayloadSignatureJWT的工作方式基于JWT的身份认证与Session-Cookie方式的区别JWT方式认证的好处JWT方式认证的坏处总结前言
小伙伴们老顾在上一篇微服务下的分散式session该如何管理?介绍了Session实现方式,这篇文章中我们来了解一下JWT是何方神圣?以及JWT来实现分散式Session。JWT是什么
JWT一看就是简称,它的全称JSON Web Token,从字面上我们看出1、资料是JSON格式
2、用于Web应用
3、是一个Token,也就是一个令牌方式
看看官方的说明,它定义了一种紧凑且自包含的方式,用于在各方之间以JSON物件进行安全传输资讯。这些资讯可以通过对称/非对称方式进行签名,防止资讯被串改。
紧凑的含义:就是JWT比较小,资料量不大,可以通过URL、POST引数或Header请求头方式进行传输。
自包含的含义:jwt可以让使用者自定义JWT里面包含的使用者资讯,如:姓名、昵称等(不要放隐密的资讯)。从而避免了多次查询数据库。
JWT资料结构
JWT由三个部分组成1、Header2、Payload
3、Signature
三者组合在一起Header.Payload.Signature
案例
看上去是不是满乱,我们来依次看下里面的结构。
Header
这个是JWT第一段资料,表示头部资讯,主要的作用是描述JWT的元资料,上面的案例就是:{
alg: "HS256",
typ: "JWT"
}
1、alg属性表示签名的算法,预设算法为HS256,可以自行别的算法。
2、typ属性表示这个令牌的型别,JWT令牌就为JWT。
上面的JSON资料会通过Base64算法进行编码而成,看工具图
Payload
此为JWT第二段资料,用来存放实际需要传递的资料。JWT官方也规定了7个字段供选用当然除了官方字段,我们可以自定义字段,以上面的案例,我们看下实际的资料
注意:这段也是用Base64算法,JWT预设是不加密的,任何人都可以获取,只要进行Base64解码就行了,所以不要把隐密的资讯放到JWT中
Signature
此为JWT第三段资料,主要作用是对前面两段的资料进行签名,防止资料篡改。一般我们进行签名的时候会有个金钥(secret),只有服务器知道,然后利用Header中的签名算法进行签名,公式如下:HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret)
算出签名后,把Header、Payload、Signature三个部分拼成一个字串,之间用(.)分隔,这样就可以把组合而成的字串返回给使用者了。
JWT的工作方式
在使用者进行认证登入时,登入成功后服务器会返回一个JWT给客户端;那这个JWT就是使用者的凭证,以后到哪里去都要带上这个凭证token。尤其访问受保护的资源的时候,通常把JWT放在Authorization header中。要用 Bearer schema,如header请求头中:Authorization: Bearer
基于JWT的身份认证
上面的JWT的工作方式,其实就是一个完整的身份认证流程,我们这里把这个讲的在通俗一点。1、使用者提供使用者名称和密码登入
2、服务器校验使用者是否正确,如正确,就返回token给客户端,此token可以包含使用者资讯
3、客户端储存token,可以储存在cookie或者local storage
4、客户端以后请求时,都要带上这个token,一般放在请求头中
5、服务器判断是否存在token,并且解码后就可以知道是哪个使用者
6、服务器这样就可以返回该使用者的相关资讯了
这个流程小伙伴们有没有发现,使用者资讯是放在JWT中的,是存放在客户端(cookie,local storage)中的,服务器只需解码验证就行了,就可以知道获取到使用者资讯。而我们之前的Session方式就不一样。
与Session-Cookie方式的区别
Session-Cookie方式的这里就不多作介绍了,之前文章已经介绍了。直接上图说明区别上图是Sesson服务器方式,我们发现Session使用者资讯是在服务器端储存的。
我们再来看看JWT方式
上面的token即使用者资讯是储存在客户端的,服务器端只要解码即可。
JWT方式认证的好处
1、因为token储存在客户端,服务器只负责解码。这样不需要占用服务器端资源。2、服务器端可以无限扩充套件,负载均衡器可以将使用者传递到任何服务器,服务器都能知道使用者资讯,因为jwt里面包含了。
3、资料安全,因为有签名,防止了篡改,但资讯还是透明的,不要放敏感资讯。
4、放入请求头提交,很好的防止了csrf攻击,
说了这么多的好处,那是不是JWT就非常适合替换掉Session方式呢?
JWT方式的坏处
一、token失效问题JWT方式最大的坏处就是无法主动让token失效,小伙伴们会说token不是有过期时间吗?是的,token本身是有过期时间,但token一旦发出,服务器就无法收回。
如:一个jwt的token的失效时间是3天,但我们发现这个token有异常,有可能被人登入,那真实的使用者可以修改密码。但是即使修改了密码,那个异常的token还是合法的,因为3天的失效时间未到,我们服务器是没法主动让异常token失效。
二、资料延时,不一致问题
还有个问题就是因为jwt中包含了使用者的部分资讯,如果这些部分资讯修改了,服务器获取的还是以前的jwt中的使用者资讯,导致资料不一致。
总结
小伙伴们怎么去选择Session的方式,是用传统的Sesion-Cookie服务器方式,还是用JWT方式,具体集合业务看。不过老顾这里推荐还是用传统的方式,因为以后的业务很有可能会用到使用者Session。好了,谢谢!!!-End-
如有收获,请帮忙转发,您的鼓励是作者最大的动力,谢谢!
10几年的经验实战分享
相关微服务,分散式,高并发,高可用,企业实战,干货等原创文章正在路上
欢迎关注头条号:老顾聊技术
精品原创技术分享,知识的组装工
推荐阅读
1、Mysql索引结构演变,为什么最终会是那个结构呢?让你一看就懂
2、一场比赛涉及到的知识,用通俗易通的方式介绍并发协调
3、企业实战Redis全方面思考,你思考了吗?
4、面试题:Thread的start和run的区别
5、面试题:什么是CAS?CAS的作用以及缺点
6、如何访问redis中的海量资料?避免事故产生
7、如何解决Redis热点问题?以及如何发现热点?
8、如何设计API界面,实现统一格式返回?
9、你真的知道在生产环境下如何部署tomcat吗?
10、分享一线互联网大厂分散式唯一ID设计 之 snowflake方案
11、分享大厂分散式唯一ID设计方案,快来围观
12、你想了解一线大厂的分散式唯一ID生成方案吗?
13、你知道如何处理大资料量吗?(资料拆分篇)
14、如何永不迁移资料和避免热点? 根据服务器指标分配资料量(揭秘篇)
15、你知道怎么分库分表吗?如何做到永不迁移资料和避免热点吗?
16、你了解大型网站的页面静态化吗?
17、你知道如何更新快取吗?如何保证快取和数据库双写一致性?
18、你知道怎么解决DB读写分离,导致资料不一致问题吗?
19、DB读写分离情况下,如何解决快取和数据库不一致性问题?
20、你真的知道怎么使用快取吗?
21、如何利用锁,防止快取击穿?重构思想的重要性
22、海量订单产生的业务高峰期,如何避免讯息的重复消费?
23、你知道如何保障生产端100%讯息投递成功吗?
24、微服务下的分散式session该如何管理?