- 因为
Http是无状态的协议，每一个请求都不会受到前后请求的状态影响，所以就需要 维护和验证登录状态 。
- cookies：由于用于验证的敏感信息都保存在本地，即使进行了加密，也并不是特别安全。
- session：需要在
cookies中保存sessionID，然后在服务器中保存session，其中包括会话ID和用户ID ，同时由于session常常保存在内存中，所以会对服务器造成比较大的压力。再加上cookies的不可跨域名性（子域名之间也算跨域名），跨域操作也存在问题。
- 使用
JWT可以做到前后端脱离，解决跨域问题，消除服务器存储session的压力，但是同时增加了计算压力。这两者怎么选择，开发者可以自行考虑。
- 首先
Basic Auth是一种最简单的认证方法，但是由于每次请求都带用户名和密码，频繁的传输肯定不安全，所以才有cookies和session的运用。如果token不刷新，那么token就相当于上面的用户名+密码，只要获取到了，就可以一直盗用，因此token设置有效期并能够进行刷新是必要的。
- 有效期越长，风险性越高，有效性越短，刷新频率越高，刷新就会存在刷新开销，所以这需要综合考虑。一般考虑的范围是：15min ~ 120min。
- 上面考虑的 15min ~ 120min，会存在一个问题，就是重放攻击风险，防御这个风险，在 JWT 可用的方案是每次请求后都刷新一次
token，但这样又会存在一个新的问题：并发请求。一次并发请求是用的一个token，第一个完成的请求会导致后面的请求全部失败。可用的解决方案是设置宽限时间，即一个token刷新后，旧token仍然短暂的可用。可惜这样并不能完美的解决重放攻击，只是增大了不法者攻击的成本。这个问题在 JWT 中并没有很好的解决。
因为无法完全解决重放攻击，所以在因重放攻击会导致巨大安全问题和损失的地方，建议使用其他安全认证措施。而日常Api使用建议如下设置：
有效时间：15min ~ 120min
刷新时间：7天 ~ 30天
宽限时间：60s