jwt前后端整合方案

一、jwt 是什么

JWT 全称，JSON Web Token，是一个以 JSON 为基准的标准规范。

举例：服务器认证以后，生成一个 JSON 对象，发回给用户，就像下面这样

{
  "姓名": "brook",
  "角色": "前端攻城狮",
  "帅气指数": "5 颗星"
}

以后，用户与服务端通信的时候，都要发回这个 JSON 对象。服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名（详见后文）。
将上面的 JSON 对象使用 Base64URL 算法（详见后文）转成字符串。

我们先看看 jwt 的真实面目

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MSwibmFtZSI6ImFkbWluIiwidXNlcm5hbWUiOiJhZG1pbiIsInBvc2l0aW9uIjoiIiwicGhvbmUiOm51bGwsImVtYWlsIjpudWxsLCJyb2xlIjpbImFkbWluIl0sImF2YXRhciI6Imh0dHA6Ly9pbWcuZG9uZ3FpdWRpLmNvbS91cGxvYWRzL2F2YXRhci8yMDE1LzA3LzI1L1FNMzg3bmg3QXNfdGh1bWJfMTQzNzc5MDY3MjMxOC5qcGciLCJpbnRyb2R1Y3Rpb24iOiIiLCJjcmVhdGVfdGltZSI6IjIwMTctMTEtMDJUMTg6MTU6NDguMDAwWiIsInVwZGF0ZV90aW1lIjoiMjAxNy0xMS0yNlQwNjozMzoxNy4wMDBaIiwiaWF0IjoxNTM5MjQ0NjQ1fQ.cRg7ZAQ-1ZBiJUPDx6naQupUMK2BLHmIusMQZrnqVpG

它是一个很长的字符串，中间用点（.）分隔成三个部分。三个部分依次为

    Header（头部）Payload（负载）Signature（签名）

即 header.payload.sign。

Header 部分是一个 JSON 对象，描述 JWT 的元数据。
Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据。JWT 规定了 7 个官方字段，供选用。
Signature 部分是对前两部分的签名，防止数据篡改。

关于这三部分的详解，可以具体参考阮一峰老师的文章：http://www.ruanyifeng.com/blo…

在使用 jwt 的时候建议放在 HTTP 请求的头信息 Authorization 字段里面，如下

    Authorization: Bearer <token>

二、jwt 的好处

• 前后端分离：使用 JWT 作为接口鉴权不需要前端代码发布到后端指定目录下，可以完全跨域，前端项目可以单独部署
• 减轻服务端内存负担：比起使用 session 来保存 cookie，JWT 自身包含了所有信息，通过解密即可验证（当然啦，这个通过吧 session 存在 redis 来避免）
• 安全性：防止 CSRF 攻击
• 移动端：对于无法使用 cookie 的一些移动端，JWT 能够正常使用
• 部署：服务器不需要保存 session 数据，无状态，容易扩展

PS：为什么不写为什么使用 jwt 呢，因为它其实还是存在不少缺点的，需要根据使用业务场景确定，不是所有的场景都适合使用 jwt，甚至网上有些帖子都是在评论 jwt 比较鸡肋的。具体可以看分析
https://juejin.im/entry/59748…

三、jwt 怎么使用

直接上图，流程如下

我们以 Eggjs 项目为例，使用 koa-jwt 这个库
https://github.com/koajs/jwt

后端 (以 Eggjs 项目为例)

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

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

• match 指 egg 路由匹配到相应前缀，则会使用当前的中间件。可以使用正则表达式去匹配，推荐 api 前缀定为 api。
• secret 指 jwt 的加密密钥。
• unless 指指定的路由不经过此中间件，一般为 login 接口

PS：egg 中使用插件有全局模式和中间件模式。全局模式应该使用 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 会自动往 middleware 的中间件里注入配置。在中间件里就可以使用 koa-jwt 对我们的接口进行保护

3、在登录接口里做好 jwt 发放，剔除密码等敏感信息

    * login() {
      const params = this.ctx.request.body;
      const rule = {
        username: 'string',
        password: 'string'
      };
      this.ctx.validate(rule, params);
      // 调用 service 进行业务处理
      const res = yield this.service.user.login(params);
      // 获取 jwt 的配置
      let {jwt:jwtConf} = app.config;
      // 使用密钥对用户数据进行加密，生成 jwt
      let token = jwt.sign(res,jwtConf.secret);
      res.token = token;
      this.ctx.body = this.ctx.helper.success(res);
    }

前端

1、登录时使用用户名和密码请求登录接口，拿到接口返回的 jwt，把 jwt 存储到 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 存储到 localStorage 里
          LocalStorage.setItem('token', data.payload.token)
          resolve(data)
        }).catch(error => {reject(error)
        })
      })
    }

PS：网上关于 jwt 应该存储到哪里有一篇分析，推荐是存到 cookie 里，因为可以避免 XSS 攻击，链接如下：
https://blog.csdn.net/loveyou…

经过实践，假如在服务端把 token 写入 cookie，并设置为 httpOnly，本地前端是获取不到 cookie 里的 token 的，也就没办法在 header 里带上 token 给后端校验，不可行；所以 token 还是需要让前端自己存储，而前端把 token 存储在 cookie 是没办法设置 httpOnly 的，所以规避不了 XSS 攻击。不管是在放 localStorage 和 cookie 里都会遇到 XSS 的问题，这个只能通过对用户输入进行转码来防范；而放在 localStorage 里会比放在 cookie 里好，因为每次请求不会在 cookie 里又带上 token，减少了请求体的大小。

综上所述，我认为 token 应该让前端存储在 localStorage 里，同时做好 XSS 防范。

2、前端在后续请求的时候在 header 里带上 jwt

推荐的做法是使用请求拦截器，推荐使用 axios

    import axios from 'axios'
    
    // 创建 axios 实例
    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)
    })

写完基本流程之后我们带上 jwt 请求一个接口看看效果

返回结果正常。同时，我们也验证一下没有 token 的情况下。我们手动清除了 cookie 再请求一次接口

接口会返回 unauthorizeError，这个是我们期待的返回结果。当然啦，我们也可以在后端 catch 这个错误，返回更加友好的信息，例如 401，让前端提示会话过期并自动跳转到登录页。我们简单演示这一步就先跳过了。

到这里，基于 jwt 的前后端分离实现方案就搞定啦！

四、关于 jwt 的一些思考

实际上，jwt 在使用的过程中有一个比较致命的缺点，就是一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。这对于要临时禁止某个用户的操作，修改某个用户权限并马上生效的业务场景，是满足不了的，而对于做得比较完善的业务系统来讲都会有类似的需求，所以是否使用 jwt，还需要谨慎评估。

JWT 的最佳用途是「一次性授权 Token」，这种场景下的 Token 的特性如下：
有效期短，只希望被使用一次。
例如分享一个文件给朋友，在指定 1 小时打开有效。

结语

以上是关于基于 jwt 的前后端分离实现方案的总结和思考。此外分享一个 accesstoken 的方案，可以作为 jwt 的替代方案，详情可以查看 loopback 框架的 Authorization，可以满足大部分的业务场景。
https://loopback.io/doc/en/lb…