前后端分离要解决的一个大问题就是信息安全，我们一起来分析应该如何实现？

一、使用session存在的问题：

  • session和cookie是为了解决http无状态的方案。session是用户保存在服务器中的状态信息，cookie中则保存jsessionId，请求服务器时，服务器读取jsessionId从而确定用户的身份信息，而session+cookie用在restful接口上破坏了其“无状态”的特性，session运行时都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。这也是restful最致力于通过“无状态”解决的问题。如果使用session，那么restful也就没有什么意义了
  • session降低了系统扩展性。用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力
  • cookie不安全，很容易导致跨站请求伪造攻击（CSRF）

二、使用token存在的问题：

  • 如何确定token的过期时间？如果token的有效期过短，很容易造成用户用着用着就掉线的情况，降低用户体验。但目前看来好像并没有太好的办法，只能尽量延长token的有效期，或者每隔一次前端自动向服务端请求一次token
  • token为什么要刷新吗？

首先 Basic Auth 是一种最简单的认证方法，但是由于每次请求都带用户名和密码，频繁的传输肯定不安全，所以才有 cookies 和 session 的运用。如果 token 不刷新，那么 token 就相当于上面的用户名 + 密码，只要获取到了，就可以一直盗用，因此 token 设置有效期并能够进行刷新是必要的。

  • token有效期多久合适，刷新频率多久合适？

有效期越长，风险性越高，有效性越短，刷新频率越高，刷新就会存在刷新开销，所以这需要综合考虑。而且 web 端应该设置为分钟级和小时级，而移动端应该设置为天级和周级。

  • token相对于Cookie+Session的优点，主要有下面两个：

        (1)、 CSRF 攻击

         这个原理不多做介绍，构成这个攻击的原因，就在于 Cookie + Session 的鉴权方式中，cookie 中的 session_id是由浏览器自动携带发送到服务端的，借助这个特性，攻击者就可以通过让用户误点攻击链接，达到攻击效果。而 token 是通过客户端本身逻辑作为动态参数加到请求中的，token 也不会轻易泄露出去，因此 token 在 CSRF 防御方面存在天然优势。

          (2)、适合移动应用

        移动端上不支持 cookie，而 token 只要客户端能够进行存储就能够使用，因此 token 在移动端上也具有优势。

 三、解决方案：基于JWT-Auth的token验证体系

JWT 全称 JSON Web Tokens ，是一个非常轻巧的规范。这个规范允许我们使用 JWT 在用户和服务器之间传递安全可靠的信息。它的两大使用场景是：认证和数据交换。

token主要有三种：

  1. 自定义的 token：开发者根据业务逻辑自定义的 token
  2. JWT：JSON Web Token，定义在 RFC 7519 中的一种 token 规范
  3. Oauth2.0：定义在 RFC 6750 中的一种授权规范，但这其实并不是一种 token，只是其中也有用到 token

jwt-auth的用途：
1、一是判断登陆状态（auth)，如未登陆则被拦截，然后转交给登陆模块，这需要一个中间件来完成。
2、二是管理登陆，即登陆逻辑login：

  • 登陆成功则发送给用户一个授权token
  • logout退出登陆，销毁token
  • 忘记密码forgetPassword
  • 注册signUp等

JWT的使用有两种方式：

  • 加到 url 中：?token=你的token
  • 加到 header 中，建议用这种，因为在 https 情况下更安全：Authorization:Bearer 你的token

JWT在客户端的存储有三种方式：

  • LocalStorage
  • SessionStorage
  • Cookie （缺点：不能设置 HTTPonly，因为没开 HTTPonly，所以要注意防范 XSS 漏洞）

推荐使用第三种，因为第一二种存在跨域读取限制，而 Cookie 可以使用不同的跨域策略

Cookie的跨域策略（继承关系）

子可以读父，但是父不可以读子，兄弟之间不能互相访问。举例如下：

  1. 子可以读父：a.xxx.com 和 b.xxx.com 可以读 xxx.com 的Cookie
  2. 父不可以读子：xxx.com 不能读 a.xxx.com 和 b.xxx.com 的Cookie
  3. 兄弟之间不能互相访问：a.xxx.com 和 b.xxx.com 不能互相读取Cookie

token存到Cookie里，那我不是又变得和cookie+session一样了吗？

其实不然，因为token存到cookie里，只是用到了其存储机制，而没有利用其去鉴权。也就是说我只是简单存一下，并没有期望浏览器带上 token 去鉴权，将 token 加入请求这部分操作还是需要我们手动进行的。

JWT相对于一般token的优点：

(1)、无状态

     因为 JWT 的有效期完全与其载荷中编码的过期时间，服务端不维护任何状态，因此 JWT一般情况下是无状态的，无状态最大的优势在于三点：

  1. 节省服务器的资源：因为服务端无需维护一个状态，因此能够节省服务端原先保存这些状态所花费的资源
  2. 适合分布式：因为服务端无需维护状态，因此如果服务端是多台服务器组成的分布式集群，那么无需像『有状态』一样互相同步各自的状态。
  3. 时间换空间：因为 token 的校验时通过签名校验来进行的，签名校验消耗的是 CPU 时间，而『有状态』是需要通过客户端提供的凭据对服务端现有的状态进行一次查询，消耗的是 I/O 和内存、磁盘空间。通常对于一个 Web 服务来说，其属于 I/O 密集型，因此通过时间换空间这一操作，可以提高整体的硬件使用率。

(2)、编码数据

     因为 JWT 能够在载荷中编码了部分信息，所以如果把常用数据编码进去的话，能够大大减少数据库的查询次数，不过有两点需要额外注意的：

  1. 载荷信息是明文编码的，所以不能编码敏感信息在里面，如果要编码可以先加密再编码进去
  2. token 在每次请求时都会进行传输，所以载荷中不能编码过多的信息，否则会降低传输效率

JWT如何防止token被盗？
因为 token 中包含了登陆状态，因此一旦 token 被盗，那么就会被人盗用身份。那么 token 针对被盗的防范措施整理如下：

  • 使用 HTTPS 传输：从传输层的角度解决问题
  • HTTPOnly：从存储层的角度解决问题，防止 XSS 攻击窃取 cookie，但是这种方案其实存在问题，因为这样 js 就无法读取 token 并把它加到 header 头中了。所以不开启 HTTPOnly 的话必须要额外注意防范 XSS 攻击。
  • 在 token 中嵌入客户端指纹：通过客户端指纹，即使黑客盗取了你的 cookie，他也无法用你的 cookie 进行请求。
  • 设置较短的 token 有效期：这样如果 token 被盗，只要超过一定时限就无法使用。