前后端分离架构带来的好处一搜一大堆，我们来看一下分离后后端接口的安全问题。
前后端分离架构现状：
前端：vue项目，Nginx部署
后端：node.js和java项目
这样的情况后端api是暴露在外网中，因为常规的web项目无论如何前端都是要通过公网访问到后台api的，带来的隐患也有很多。
1.接口公开，谁都可以访问
2.数据请求的参数在传输过程被篡改
3.接口被重复调用
...
session和cookie局限性
session和cookie都是客户端与服务端通讯需要提供的认证，当客户端的值和服务器的值吻合时，才允许请求api，解决了第1个问题，但是当攻击者获取到了传输过程中的session或者cookie值后，就可以进行第2、3种攻击了
JWT的token机制
JWT标准的token包含三部分：
1.header(头部)，头部信息主要包括（参数的类型--JWT,签名的算法--HS256）
2.poyload(负荷)，负荷基本就是自己想要存放的信息(因为信息会暴露，不应该在载荷里面加入任何敏感的数据)，有两个形式，下边会讲到
3.sign(签名)，签名的作用就是为了防止恶意篡改数据
头部（Header）
头部用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等
{
"typ": "JWT",
"alg": "HS256"
}
将上面的JSON对象进行[base64编码]可以得到下面的字符串。这个字符串我们将它称作JWT的Header
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
载荷（Payload）
Payload也是一个JSON对象。包含了一些其他的信息
{
"iss": "John Wu JWT",
"iat": 1441593502,
"exp": 1441594722,
"aud": "www.example.com",
"sub": "jrocket@example.com",
"from_user": "B",
"target_user": "A"
}
这里面的前五个字段都是由JWT的标准所定义的。
* `iss`: 该JWT的签发者
* `sub`: 该JWT所面向的用户
* `aud`: 接收该JWT的一方
* `exp`(expires): 什么时候过期，这里是一个Unix时间戳
* `iat`(issued at): 在什么时候签发的
将上面的JSON对象进行[base64编码]可以得到下面的字符串。这个字符串我们将它称作JWT的Payload
eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0
注意：Base64是一种编码，也就是说，它是可以被翻译回原来的样子来的。它并不是一种加密过程。
签名（Sign）
将上面的两个编码后的字符串都用句号.连接在一起（头部在前），就形成了
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0
最后，我们将上面拼接完的字符串用HS256算法进行加密。在加密的时候，我们还需要提供一个密钥（secret）。如果我们用mystar作为密钥的话，那么就可以得到我们加密后的内容
rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM
这一部分叫做签名
最后将这一部分签名也拼接在被签名的字符串后面，我们就得到了完整的JWT
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM
为什么要使用签名
签名解决了数据传输过程中参数被篡改的风险
一般而言，加密算法对于不同的输入产生的输出总是不一样的，如果有人对Header以及Payload的内容解码之后进行修改，再进行编码的话，那么新的头部和载荷的签名和之前的签名就将是不一样的。而且，如果不知道服务器加密的时候用的密钥的话，得出来的签名也一定会是不一样的。
服务器应用在接受到JWT后，会首先对头部和载荷的内容用同一算法再次签名。如果服务器应用对头部和载荷再次以同样方法签名之后发现，自己计算出来的签名和接受到的签名不一样，那么就说明这个Token的内容被别人动过的，我们应该拒绝这个Token
如何防范Replay Attacks
解决了篡改数据的问题，还有第3个问题，那就是攻击者不修改数据，只是重复攻击
所谓重复攻击就是攻击者发送一个后端服务器已接收过的包，来达到攻击系统的目的。
比如在浏览器端通过用户名/密码验证获得签名的Token被木马窃取。即使用户登出了系统，黑客还是可以利用窃取的Token模拟正常请求，而服务器端对此完全不知道，因为JWT机制是无状态的。
可以在Payload里增加时间戳并且前后端都参与来解决：
1.前端生成token时，在payload里增加当前时间戳
2.后端接收后，对解析出来的时间戳和当前时间进行判断，
3.如果相差特定时间内（比如2秒），允许请求否则判定为重复攻击
