第一种方案：（不考虑完全前后端分离可以用）

　　直接由服务端设置cookie到浏览器（客户端）jwt token是储存在cookie的（服务器生成直接发送到客户端）。客户端的cookie值是http请求后浏览器自动发送到服务器的（标记1），服务器（程序语言怎么获取就怎么获取）直接获取就行，做验证

且需要设置 cookie为 httpOnly 为true（这个设置后js不能操作设置httpOnly 的cookie，就意味客户端不能操作cookie 这样一来就能防止xss攻击（这个不懂百度自己看））

但是不能防csrf攻击（这个在用户登录时会有cookie的信息，所以在没有安全退出时去访问不安全的网站时有可能被此网站利用去重要操作，就是cookie的优点也是缺点（1）带来）

所以需要在重要的表单提交（post）或者重要数据展示（前后分离情况有get请求也有post请求）做csrf_token(这个不清楚百度)

例：

 原本的需要作为验证物的csrf_token是存在服务端的（因为只要比对是一致就行，和jwt不同 jwt需要签名方式来验证（对称加密或者非对方加密）），但可以考虑放在 jwt 的 载体的信息中（Payload）

例：

表单提交验证后验证jwt 在比对 Payload中的 csrf_token。

优点：不用考虑xss 综合下来是比较安全的。

缺点：（不算怎么符合jwt 规范，本来jwt天然防csrf攻击）毕竟不能前后端分离。

第二种方案：

　　第二种方式都比较符合jwt规范（restful api），项目前后端分离需要Ajax类似的请求，但是又分为3小种

　　1、是由客户端去请求获取到客户端生成的jwt token，存放在cookie。

　　jwt token 存储在cookie 同时设置cookie为 httpOnly（避免xss，这种可以在同样可以服务操作cookie）（如果是前后端分离同时要求安全系数高些推荐) 

　　这种方式还是需要保证csrf （因为需要的jwt存放cookie为 httpOnly后不能js操作 是但是每次http请求自动发送到服务器的，所以需要避免csrf ）

　　就是两个token 一个授权的token（但又可以两个分access_token和refresh_token，但一般可能只有一个access_token就够了要求安全性的话那就两个，详见https://www.cnblogs.com/yangshiyi/p/16920712.html）

      另一个不同的是防止表单提交时避免csrf攻击的token（csrf_token）

    操作：需要把 csrf_token放在 jwt（就是权鉴的token） 的载体中（Payload）

例：

    同时需要csrf_token 传到客户端存在cookie（不设置httpOnly）中 然后每次表单请求需要从客户端cookie取出来，由于前后端分离需要做ajax类似请求来请求和提交会发送到服务器

    所有就需要放到http 的Request Header 报头的 Authorization字段中（这种跨域的话一般需要服务器(apache )设置报头 ，才能取到）http请求，服务器端能获取。

例：

  服务端获取httpOnly cookie的 jwt和 Authorization中的csrf_token。jwt验证通过后，取出jwt载体中的csrf_token和前端传过来的Authorization字段带的值（csrf_token）进行比对一致就通过允许表单提交。

  apache 重写配置举例 ：（apache 服务器可能拿不到需要重写规则）

（当然有疑问，csrf_token是存在客户端且可以对cookie操作很容易遭遇xss攻击，但jwt 是放在httpOnly cookie的，xss没办法拿到且有时效性，同时验证才能做某些操作）

优点：较为符合jwt规范也适合前后端分离的项目，同时双层验证安全性高些

缺点：有些客户端不支持cookie，实现可能有些繁琐。

==========================================================================================================

2、jwt 的token储存在localstorage，用法是和 1 的方案类似 ，如果只是 1 的方案只考虑cookie仅仅作为储存，那用法者2的方案的用法一样。不设置httpOnly ，js可以对cookie操作

例：

优点：自带csrf防御不用额外做表单csrf_token。符合jwt规定且过程容易实现。

缺点：需要（xss防御）localstorage的生命周期是，会永久保存在客户端。这如需要就得手动清除。可能被xss攻击拿到jwt。

可能需要额外做安全（比如设置token黑名单还有，或者设置更新token接口请求的次数，用来及时止损，但就不算符合jwt规范了）

===================================================================================================================

3、储存在sessionStorage，用法和localstorage类似

例：

优点：特定需求（比如打开客服系统关闭单页窗口退出客服，还有推临时广告之类）临时操作，一次性。

缺点：就是生命周期是，关闭页面和浏览器会清除，不适合保持长时间登录会话。

jwt的方案，看需求来选择吧，抛开需求谈实现就是耍流氓，哈哈。

其他：

其他的方案不符合直接脱离jwt规范了（主要原则就是无状态，是由客户端来控制的会话状态）。

总的来说，需要的安全性很高的就那还得需要服务器来控制了，毕竟脱离了服务端控制是有风险的。

至于为啥还选择jwt，就是可以在此基础服务端可以接手来控制，对比传统的cookie-session拓展性强，且实现过程和传统的也没大难点。

还有jwt为贴合restful api方面（就是前后端分离）的应用的开发（app、小程序、移动端网站、pc网站)，一般多端下能通用的情况，就减少多套实现繁琐

当然传统网站（可以直接用cookie-session)。趋势嘛就不知道，毕竟很多项目还是“老古董”。