1 如何防止token劫持或者说是泄露？

token肯定会存在泄露的问题。比如我拿到你的手机，把你的token拷出来，在过期之前就都可以以你的身份在别的地方登录。

解决这个问题的一个简单办法

在存储的时候把token进行对称加密存储，用时解开。

将请求URL、时间戳、token三者进行合并加盐签名或者缓存用户的ip地址也是不错的选择，服务端校验有效性。

这两种办法的出发点都是：窃取你存储的数据较为容易，而反汇编你的程序hack你的加密解密和签名算法是比较难的。然而其实说难也不难，所以终究是防君子不防小人的做法。

总结

在Web应用中，别再把JWT当做session使用，在绝大多数场景下，传统的cookie-session机制工作得更好；

JWT适合一次性的安全认证，颁发一个有效期极短的JWT，即使暴露了危险也很小。

2 使用JWT代替cookie-session还有如下缺点：

由于JWT要求有一个秘钥，还有对应的算法，生成的令牌看上去不可读，不少人误认为该令牌是被加密的。但实际上秘钥和算法是用来生成签名的，令牌本身不可读是因为进行了base64编码。但是base64编码是可以直接进行解码的。如果JWT中如果保存了敏感的信息，相对于cookie-session将数据存储在服务端来说，更不安全。

3 如何防止表单重复提交问题

网络延迟时，重复点击提交按钮，有可能发生重复提交表单问题。

解决方案：

1.数据库主键唯一。

2.提交成功后重定向。

3.使用 JavaScript 解决，使用标记位，提交后隐藏或不可用提交按钮。 使用 Session 解决： 生成唯一的 Token 给客户端，客户端第一次提交时带着这个 TOken,后台与 Session 中的 进行对比。一样则提交成功并清除 Session 中的 Token。不一样则提交失败。

4 取代JWT方案

有的人说的我看不懂什么方案好像也是个写好的框架做整合我研究研究再写

替代方案PAST

PAST（平台不可知的安全令牌）是安全无状态令牌的规范和参考实现。

与JSON Web Tokens（JWT）不同的是，PAST只允许开发人员进行足够的绑定，而PAST只允许安全的操作。JWT给你“算法敏捷性”，PAST给你“版本化的协议”。你不可能以不安全的方式使用PAST 。