摘要：到這里，基于的前后端分離實(shí)現(xiàn)方案就搞定啦四關(guān)于的一些思考實(shí)際上，在使用的過(guò)程中有一個(gè)比較致命的缺點(diǎn)，就是一旦簽發(fā)了，在到期之前就會(huì)始終有效，除非服務(wù)器部署額外的邏輯。結(jié)語(yǔ)以上是關(guān)于基于的前后端分離實(shí)現(xiàn)方案的總結(jié)和思考。

JWT全稱， JSON Web Token，是一個(gè)以JSON為基準(zhǔn)的標(biāo)準(zhǔn)規(guī)范。

舉例：服務(wù)器認(rèn)證以后，生成一個(gè) JSON 對(duì)象，發(fā)回給用戶，就像下面這樣

{
  "姓名": "brook",
  "角色": "前端攻城獅",
  "帥氣指數(shù)": "5顆星"
}

以后，用戶與服務(wù)端通信的時(shí)候，都要發(fā)回這個(gè) JSON 對(duì)象。服務(wù)器完全只靠這個(gè)對(duì)象認(rèn)定用戶身份。為了防止用戶篡改數(shù)據(jù)，服務(wù)器在生成這個(gè)對(duì)象的時(shí)候，會(huì)加上簽名（詳見(jiàn)后文）。
將上面的 JSON 對(duì)象使用 Base64URL 算法（詳見(jiàn)后文）轉(zhuǎn)成字符串。

我們先看看jwt的真實(shí)面目

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwidXNlcm5hbWUiOiJhZG1pbiIsInBvc2l0aW9uIjoiIiwicGhvbmUiOm51bGwsImVtYWlsIjpudWxsLCJyb2xlIjpbImFkbWluIl0sImF2YXRhciI6Imh0dHA6Ly9pbWcuZG9uZ3FpdWRpLmNvbS91cGxvYWRzL2F2YXRhci8yMDE1LzA3LzI1L1FNMzg3bmg3QXNfdGh1bWJfMTQzNzc5MDY3MjMxOC5qcGciLCJpbnRyb2R1Y3Rpb24iOiIiLCJjcmVhdGVfdGltZSI6IjIwMTctMTEtMDJUMTg6MTU6NDguMDAwWiIsInVwZGF0ZV90aW1lIjoiMjAxNy0xMS0yNlQwNjozMzoxNy4wMDBaIiwiaWF0IjoxNTM5MjQ0NjQ1fQ.cRg7ZAQ-1ZBiJUPDx6naQupUMK2BLHmIusMQZrnqVpG

它是一個(gè)很長(zhǎng)的字符串，中間用點(diǎn)（.）分隔成三個(gè)部分。三個(gè)部分依次為

    Header（頭部）
    Payload（負(fù)載）
    Signature（簽名）

即header.payload.sign。

Header 部分是一個(gè) JSON 對(duì)象，描述 JWT 的元數(shù)據(jù)。
Payload 部分也是一個(gè) JSON 對(duì)象，用來(lái)存放實(shí)際需要傳遞的數(shù)據(jù)。JWT 規(guī)定了7個(gè)官方字段，供選用。
Signature 部分是對(duì)前兩部分的簽名，防止數(shù)據(jù)篡改。

關(guān)于這三部分的詳解，可以具體參考阮一峰老師的文章：http://www.ruanyifeng.com/blo...

在使用jwt的時(shí)候建議放在 HTTP 請(qǐng)求的頭信息Authorization字段里面，如下

    Authorization: Bearer 

前后端分離：使用JWT作為接口鑒權(quán)不需要前端代碼發(fā)布到后端指定目錄下，可以完全跨域，前端項(xiàng)目可以多帶帶部署

減輕服務(wù)端內(nèi)存負(fù)擔(dān)：比起使用session來(lái)保存cookie，JWT自身包含了所有信息，通過(guò)解密即可驗(yàn)證（當(dāng)然啦，這個(gè)通過(guò)吧session存在redis來(lái)避免）

安全性：防止CSRF攻擊

移動(dòng)端：對(duì)于無(wú)法使用cookie的一些移動(dòng)端，JWT能夠正常使用

部署：服務(wù)器不需要保存session數(shù)據(jù)，無(wú)狀態(tài)，容易擴(kuò)展

PS：為什么不寫(xiě)為什么使用jwt呢，因?yàn)樗鋵?shí)還是存在不少缺點(diǎn)的，需要根據(jù)使用業(yè)務(wù)場(chǎng)景確定，不是所有的場(chǎng)景都適合使用jwt，甚至網(wǎng)上有些帖子都是在評(píng)論jwt比較雞肋的。具體可以看分析
https://juejin.im/entry/59748...

直接上圖，流程如下

我們以Eggjs項(xiàng)目為例，使用koa-jwt這個(gè)庫(kù)
https://github.com/koajs/jwt

1、在config.default.js 中以中間件的方式使用koa-jwt

  config.middleware = ["compress", "errorHandler","jwt"];
  // 加上配置
  config.jwt = {
    match: "/api",
    secret: "abiao",
    unless: ["/api/user/login"],
  };

match指egg路由匹配到相應(yīng)前綴，則會(huì)使用當(dāng)前的中間件。可以使用正則表達(dá)式去匹配，推薦api前綴定為api。

secret指jwt的加密密鑰。

unless指指定的路由不經(jīng)過(guò)此中間件，一般為login接口

PS：egg中使用插件有全局模式和中間件模式。全局模式應(yīng)該使用egg的插件，中間件模式可以使用第三方koa的插件

2、在middlewares文件夾目錄下增加jwt中間件

jwt.js

    const jwt = require("koa-jwt");
    module.exports = (options, app) => {
      let jwtMiddlerware = jwt(
        {
          secret: options.secret,
        }
      );
      if (options.unless) {
        jwtMiddlerware = jwtMiddlerware.unless({path: options.unless})
      }
      return jwtMiddlerware
    };

egg會(huì)自動(dòng)往middleware的中間件里注入配置。在中間件里就可以使用koa-jwt對(duì)我們的接口進(jìn)行保護(hù)

3、在登錄接口里做好jwt發(fā)放，剔除密碼等敏感信息

    * login() {
      const params = this.ctx.request.body;
      const rule = {
        username: "string",
        password: "string"
      };
      this.ctx.validate(rule, params);
      // 調(diào)用 service 進(jìn)行業(yè)務(wù)處理
      const res = yield this.service.user.login(params);
      // 獲取jwt的配置
      let {jwt:jwtConf} = app.config;
      // 使用密鑰對(duì)用戶數(shù)據(jù)進(jìn)行加密，生成jwt
      let token = jwt.sign(res,jwtConf.secret);
      res.token = token;
      this.ctx.body = this.ctx.helper.success(res);
    }

1、登錄時(shí)使用用戶名和密碼請(qǐng)求登錄接口，拿到接口返回的jwt，把jwt存儲(chǔ)到localStorage里

    LoginByUsername({ commit }, userInfo) {
      const username = userInfo.username.trim()
      return new Promise((resolve, reject) => {
        loginByUsername(username, userInfo.password).then(response => {
          const data = response.data
          // 把jwt存儲(chǔ)到localStorage里
          LocalStorage.setItem("token", data.payload.token)
          resolve(data)
        }).catch(error => {
          reject(error)
        })
      })
    }

PS：網(wǎng)上關(guān)于jwt應(yīng)該存儲(chǔ)到哪里有一篇分析，推薦是存到cookie里，因?yàn)榭梢员苊釾SS攻擊，鏈接如下：
https://blog.csdn.net/loveyou...

經(jīng)過(guò)實(shí)踐，假如在服務(wù)端把token寫(xiě)入cookie，并設(shè)置為httpOnly，本地前端是獲取不到cookie里的token的，也就沒(méi)辦法在header里帶上token給后端校驗(yàn)，不可行；所以token還是需要讓前端自己存儲(chǔ)，而前端把token存儲(chǔ)在cookie是沒(méi)辦法設(shè)置httpOnly的，所以規(guī)避不了XSS攻擊。不管是在放localStorage和cookie里都會(huì)遇到XSS的問(wèn)題，這個(gè)只能通過(guò)對(duì)用戶輸入進(jìn)行轉(zhuǎn)碼來(lái)防范；而放在localStorage里會(huì)比放在cookie里好，因?yàn)槊看握?qǐng)求不會(huì)在cookie里又帶上token，減少了請(qǐng)求體的大小。

綜上所述，我認(rèn)為token應(yīng)該讓前端存儲(chǔ)在localStorage里，同時(shí)做好XSS防范。

2、前端在后續(xù)請(qǐng)求的時(shí)候在header里帶上jwt

推薦的做法是使用請(qǐng)求攔截器，推薦使用axios

    import axios from "axios"
    
    // 創(chuàng)建axios實(shí)例
    const service = axios.create({
      baseURL: "/",
      timeout: 5000
    })
    
    // request攔截器
    service.interceptors.request.use(config => {
      if (LocalStorage.getItem("token")) {
        config.headers["authorization"] = "Bearer " + LocalStorage.getItem("token")
      }
      return config
    }, error => {
      Promise.reject(error)
    })

寫(xiě)完基本流程之后我們帶上jwt請(qǐng)求一個(gè)接口看看效果

返回結(jié)果正常。同時(shí)，我們也驗(yàn)證一下沒(méi)有token的情況下。我們手動(dòng)清除了cookie再請(qǐng)求一次接口

接口會(huì)返回unauthorizeError，這個(gè)是我們期待的返回結(jié)果。當(dāng)然啦，我們也可以在后端catch這個(gè)錯(cuò)誤，返回更加友好的信息，例如401，讓前端提示會(huì)話過(guò)期并自動(dòng)跳轉(zhuǎn)到登錄頁(yè)。我們簡(jiǎn)單演示這一步就先跳過(guò)了。

到這里，基于jwt的前后端分離實(shí)現(xiàn)方案就搞定啦！

實(shí)際上，jwt在使用的過(guò)程中有一個(gè)比較致命的缺點(diǎn)，就是一旦 JWT 簽發(fā)了，在到期之前就會(huì)始終有效，除非服務(wù)器部署額外的邏輯。這對(duì)于要臨時(shí)禁止某個(gè)用戶的操作，修改某個(gè)用戶權(quán)限并馬上生效的業(yè)務(wù)場(chǎng)景，是滿足不了的，而對(duì)于做得比較完善的業(yè)務(wù)系統(tǒng)來(lái)講都會(huì)有類似的需求，所以是否使用jwt，還需要謹(jǐn)慎評(píng)估。

JWT 的最佳用途是「一次性授權(quán) Token」，這種場(chǎng)景下的 Token 的特性如下：
有效期短，只希望被使用一次。
例如分享一個(gè)文件給朋友，在指定1小時(shí)打開(kāi)有效。

以上是關(guān)于基于jwt的前后端分離實(shí)現(xiàn)方案的總結(jié)和思考。此外分享一個(gè)accesstoken的方案，可以作為jwt的替代方案，詳情可以查看loopback框架的Authorization，可以滿足大部分的業(yè)務(wù)場(chǎng)景。
https://loopback.io/doc/en/lb...