目前大量互联网公司和传统软件公司都在项目上大量采用前后端分离，这也是体现社会化分工更加明晰，Web端、App端和小程序都涉及调用后端接口，传输的时候如何防止被抓包、偷窥、伪造、超时、重放。

解决方案：

token授权认证：防止未授权用户获取数据、时间戳：防止超时重放、签名：防止数据篡改
HTTPS：防止数据明文传输

Token：

• 用户用密码登录或者验证码登录成功后，服务器返回token（通常UUID）给客户端，并将Token-UserId以键值对的形式存放在缓存服务器中。
• 客户端将token保存在本地，发起后续的相关请求时，将token发回给服务器；
• 服务器检查token的有效性，有效则返回数据，若无效，分两种情况：

1. token错误，这时需要用户重新登录，获取正确的token
2. token过期，这时客户端需要再发起一次认证请求，获取新的token（具体的看服务端和客户端怎么约定处理）

时间戳：

如果时间差大于一定时间（比如：1分钟），则认为该请求失效，防止超时重放

• App启动后通过接口获取服务器时间 ServerTime，保存本地。并同时记录当前时间 LocalTime1
• 获取当前时间：LocalTime2（当前本地时间） - LocalTime1 + ServerTime

签名：

比如queryString、header、body，将它们按顺序拼接成一个字符串，然后使用秘钥签名，防止数据被篡改。如果传输不敏感信息，仅仅为了防篡改，可以使用签名；

每次HTTP请求，都需要加上timestamp参数，然后把timestamp和其他参数一起进行数字签名。因为一次正常的HTTP请求，从发出到达服务器一般都不会超过60s，所以服务器收到HTTP请求之后，首先判断时间戳参数与当前时间相比较，是否超过了60s，如果超过了则认为是非法的请求。

流水号：

每次请求生成一个唯一流水号，存放到缓存中，如果下次再使用相同的流水号请求就拒绝，防重放

HTTPS：

HTTP协议是以明文方式发送内容，因此不适合传输一些敏感信息
HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为客户端和服务器之间的通信加密

场景：

App

APP比较特殊，攻击者可以反编译源码，所以不可以在APP中存放秘钥，曾经见过有公司APP使用OAuth的Client Credential授权方式，将ClientID和ClientSecret存放在APP端，app启动时获取Token，肯定不安全应该使用APP使用者的用户名密码登录获取Token，配合使用签名、时间戳、流水号、HTTPS