通俗化讲解JWT鉴权的使用场景及结构安全

1、基于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就是这样的一种方案。

2、JWT是什么？

笔者不想用比较高大上的名词解释JWT（JSON web tokens），你能够认为JWT是一个加密后的接口访问密码，而且该密码里面包含用户名信息。这样既能够知道你是谁？又能够知道你是否能够访问应用？

• 首先，客户端须要向服务端申请JWT令牌，这个过程一般是登陆功能。即：由用户名和密码换取JWT令牌。
• 当你访问系统其余的接口时，在HTTP的header中携带JWT令牌。header的名称能够自定义，先后端对应上便可。
• 服务端解签验证JWT中的用户标识，根据用户标识从数据库中加载访问权限、用户信息等状态信息。

这就是JWT，以及JWT在应用服务开发中的使用方法。

3、JWT结构分析

下图是我用在线的JWT解码工具，解码时候的截图。注意我这里用的是解码，不是解密。

从图中，咱们能够看到JWT分为三个部分：

• Header，这个部分一般是用来讲明JWT使用的算法信息
• payload，这个部分一般用于携带一些自定义的状态附加信息（重要的是用户标识）。可是注意这部分是能够明文解码的，因此注意是用户标识，而不该该是用户名或者其余用户信息。
• signature，这部分是对前两部分数据的签名，防止前两部分数据被篡改。这里须要指定一个密钥secret，进行签名和解签。

4、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已经换了。

话说回来，若是你的服务器、或者你团队的内部人员出现漏洞，一样没有一种协议和算法是安全的。

期待您的关注

• 向您推荐博主的系列文档：《手摸手教您学习SpringBoot系列-16章97节》
• 本文转载注明出处（必须带链接，不能只转文字）：字母哥博客。