一、前言
在如今，微服务架构越来越流行了，项目也越来越多采用前后端项目分离，一般在权限控制中采用JWT进行处理。
二、JWT介绍
JWT是一种认证协议是最后输出为token,然后把token进行传到客户端，客户端访问api通过filter解析token,获得jwt中的信息，进行判断操作。
jwt分为三部分 ，header、payload
、Signature。 header是具有哈希算法、以及typ类型。
哈希算法可以采用SHA256等 ，哈希算法不是加密算法。它是值把一个值进行通过哈希碰撞生成一个加密的值，是不存在解密的，唯一解密的方式就是重复试值进行碰撞产生相同的值。
payload是值我们需要传入的信息，一般不要进行敏感的信息。然后使用Base64编码，Header也是使用Base64编码
JWT 的最后一部分是 Signature ，这部分内容有三个部分，先是用 Base64 编码的 header 和 payload ，再用加密算法加密一下，加密的时候要放进去一个 Secret ，这个相当于是一个密码，这个密码秘密地存储在服务端。
三、安全问题
1.如果其他用户获得我们电脑上的token,那么他们就能模仿真实用户进行操作（黑客监控电脑，获得网站发送的token,进行操作）？
对于敏感的api接口，需使用https 。https是在http超文本传输协议加入SSL层，它在网络间通信是加密的，所以需要加密证书。
2.我们是否可以伪造用户token进行访问？
不可以，因为你无法使用服务器的签名，就是你自己的密钥签名的信息服务器识别不了。
3.我们是否可以修改token中body的信息？
不能，修改了之后签名信息就不正确，然后就无法验证签名，说明数据被修改了。
四. csdn中的http和https的一种回复
Question:app登录后，服务端返回一个token，app存在客户端，下次再打开app时，直接读token，传token到服务端做验证，免去重新输入用户密码的麻烦，这个token存储在header里，目前看大多数app都是这样做，但如果黑客抓包获取到token，伪造http 请求，对服务器做操作，那岂不是很不安全。。。
Answer:这方法确实不好啊，不能只依赖于http的header里的东西来认证，太容易模仿。最简单的方法可能就是走https，客户端只要接受服务器端的签名即可。
理解：签名就是验证信息的唯一性，如果中间人进行获得token，那么无法进行公钥签名，服务器获得token之后还要进行解密的，因此这个方法可以进行避免攻击。
中间人如何抓包获取局域网的http请求?
五、总结
对于敏感的api接口，需使用https 。https是在http超文本传输协议加入SSL层，它在网络间通信是加密的，所以需要加密证书。
采用https 或者 代码层面也可以做安全检测，比如ip地址发生变化，MAC地址发生变化等等，可以要求重新登录