A股上市公司传智教育(股票代码 003032)旗下技术交流社区北京昌平校区

 找回密码
 加入黑马

QQ登录

只需一步,快速开始

一、基于Session的应用开发的缺陷
在我们传统的B\S应用开发方式中,都是使用session进行状态管理的,比如说:保存登录、用户、权限等状态信息。这种方式的原理大致如下:

用户登陆之后,将状态信息保存到session里面。服务端自动维护sessionid,即将sessionid写入cookie。
cookie随着HTTP响应,被自动保存到浏览器端。
当用户再次发送HTTP请求,sessionid随着cookies被带回服务器端
服务器端根据sessionid,可以找回该用户之前保存在session里面的数据。
当然,这整个过程中,cookies和sessionid都是服务端和浏览器端自动维护的。所以从编码层面是感知不到的,程序员只能感知到session数据的存取。但是,这种方式在有些情况下,是不适用的。

比如:非浏览器的客户端、手机移动端等等,因为他们没有浏览器自动维护cookies的功能。
比如:分布式应用,同一个应用部署甲、乙、丙三个主机上,实现负载均衡应用,其中一个挂掉了其他的还能负载工作。要知道session是保存在服务器内存里面的,三个主机一定是不同的内存。那么你登录的时候访问甲,而获取接口数据的时候访问乙,就无法保证session的唯一性和共享性。
当然以上的这些情况我们都有方案(如redis共享session等),可以继续使用session来保存状态。但是还有另外一种做法就是不用session了,即开发一个无状态的应用,JWT就是这样的一种方案。

二、JWT是什么?
笔者不想用比较高大上的名词解释JWT(JSON web tokens),你可以认为JWT是一个加密后的接口访问密码,并且该密码里面包含用户名信息。这样既可以知道你是谁?又可以知道你是否可以访问应用?

file

首先,客户端需要向服务端申请JWT令牌,这个过程通常是登录功能。即:由用户名和密码换取JWT令牌。
当你访问系统其他的接口时,在HTTP的header中携带JWT令牌。header的名称可以自定义,前后端对应上即可。
服务端解签验证JWT中的用户标识,根据用户标识从数据库中加载访问权限、用户信息等状态信息。
这就是JWT,以及JWT在应用服务开发中的使用方法。

三、JWT结构分析
下图是我用在线的JWT解码工具,解码时候的截图。注意我这里用的是解码,不是解密。

file

从图中,我们可以看到JWT分为三个部分:

Header,这个部分通常是用来说明JWT使用的算法信息
payload,这个部分通常用于携带一些自定义的状态附加信息(重要的是用户标识)。但是注意这部分是可以明文解码的,所以注意是用户标识,而不应该是用户名或者其他用户信息。
signature,这部分是对前两部分数据的签名,防止前两部分数据被篡改。这里需要指定一个密钥secret,进行签名和解签。
四、JWT安全么?
很多的朋友看到上面的这个解码文件,就会生出一个疑问?你都把JWT给解析了,而且JWT又这么的被大家广泛熟知,它还安全么?我用一个简单的道理说明一下:

JWT就像是一把钥匙,用来开你家里的锁。用户把钥匙一旦丢了,家自然是不安全的。其实和使用session管理状态是一样的,一旦网络或浏览器被劫持了,肯定不安全。
signature通常被叫做签名,而不是密码。比如:天王盖地虎是签名,宝塔镇河妖就被用来解签。字你全都认识,但是暗号只有知道的人才对得上。当然JWT中的暗号secret不会设计的像诗词一样简单。
JWT服务端也保存了一把钥匙,就是暗号secret。用来数据的签名和解签,secret一旦丢失,所有用户都是不安全的。所以对于IT人员,更重要的是保护secret的安全。
如何加强JWT的安全性?

避免网络劫持,因为使用HTTP的header传递JWT,所以使用HTTPS传输更加安全。这样在网络层面避免了JWT的泄露。
secret是存放在服务器端的,所以只要应用服务器不被攻破,理论上JWT是安全的。因此要保证服务器的安全。
那么有没有JWT加密算法被攻破的可能?当然有。但是对于JWT常用的算法要想攻破,目前已知的方法只能是暴力破解,白话说就是"试密码"。所以要定期更换secret并且保正secret的复杂度,等破解结果出来了,你的secret已经换了。
话说回来,如果你的服务器、或者你团队的内部人员出现漏洞,同样没有一种协议和算法是安全的。

2 个回复

倒序浏览
有任何问题欢迎在评论区留言
回复 使用道具 举报
或者添加学姐微信
DKA-2018
回复 使用道具 举报
您需要登录后才可以回帖 登录 | 加入黑马