Express + JWT用户认证最轻实践

最近给本身列了一个list，Ummm...列来列去大概是下面这个样子：

• React SSR服务端渲染
• jwt用户认证
• Vue全家桶
• 微信小程序开发
• ... 等等

好吧，谁让本身菜呢，没什么好抱怨的，一个一个来吧。正好最近看了一些token作身份认证的文章，发现其中大部分都是说token登陆怎么怎么好，反正没有几个认认真真的实现的。。。正好，秉着我是小白我怕谁的原则，继续分享一下express + jwt的填坑经历。为何题目起名是最轻实践呢？由于确实看完这个你能够大概理解token登陆的好处以及如何简单的实现一个先后端经过token进行认证的小系统。这个demo是在我第一篇文章那个脚手架上跑起来的，感兴趣的还能够回顾一下----->express-react-scaffold。具体实现就是下面这个样子：

• 不用token验证的页面正常浏览
• 须要验证的页面进行token验证
• 没有token信息或token信息过时，提示用户从新登陆，跳转到登陆页面
• 登陆成功以后每次请求携带token信息

  

这篇文章包括

• 为何要用token作身份验证（另外一种模式是session）
• 前端http请求拦截器的设置
• 后端express + jsonwebtoken实现基于token的用户身份验证

token是个啥子东西

身份认证的两种方式

在先后端分离的系统中，身份认证是十分重要的，目前经常使用的两种身份认证方式以下：

• 基于cookie
  基于cookie的服务端认证，就是咱们所熟知session，在服务端生成用户相关的 session 数据，而发给客户端 sesssion_id 存放到 cookie 中，这样用客户端请求时带上 session_id 就能够验证服务器端是否存在 session 数据，以此完成用户认证。
• 基于Token令牌
  基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用户验证后,服务端生成一个 token(hash 或 encrypt)发给客户端，客户端能够放到 cookie 或 localStorage(sessionStorage) 中，每次请求时在 Header 中带上 token ，服务端收到 token 经过验证后便可确认用户身份。

token认证的好处

• 体积小（一串字符串），于是传输速度快
• 传输方式多样，能够经过HTTP 头部（推荐）、 URL、POST 参数等方式传输严谨的结构化。它自身（在 payload 中）就包含了全部与用户相关的验证消息，如用户可访问路由、访问有效期等信息，服务器无需再去链接数据库验证信息的有效性，而且 payload 支持为应用定制化支持跨域验证，多应用于单点登陆 充分依赖无状态 API ，契合 RESTful 设计原则（无状态的 HTTP）
• 用户登陆以后，服务器会返回一串 token 并保存在本地也就是客户端，在这以后的对服务器的访问都要带上这串 token，来得到访问服务器相关路由、服务及资源的权限。 易于实现 CDN，将静态资源分布式管理
• 在传统的 session 验证中，服务端必须保存 session ID，用于与用户传过来的 cookie 验证。而一开始 sessionID 只会保存在一台服务器上，因此只能由一台 server 应答，就算其余服务器有空闲也没法应答，没法充分利用到分布式服务器的优势。 JWT 依赖的是在客户端本地保存验证信息，不须要利用服务器保存的信息来验证，因此任意一台服务器均可以应答，服务器的资源也被较好地利用。
• 对原生的移动端应用支持较好 原生的移动应用对 cookie 与 session 的支持不够好，而对 token 的方式支持较好。

JWT的组成

JWT的本质实际上就是一个字符串，它有三部分组成头部+载荷＋签名。

// Header
{
  "alg": "HS256",//所使用的签名算法
  "typ": "JWT"
}

// Payload
{
  //该JWT的签发者
  "iss": "luffy",
  // 这个JWT是何时签发的
  "iat":1441593502,
  //何时过时，这是一个时间戳
  "exp": 1441594722,
  // 接收JWT的一方
  "aud":"www.youdao.com",
  // JWT所面向的用户
  "sub":"any@126.com",
  // 上面是JWT标准定义的一些字段，除此以外还能够私人定义一些字段
  "form_user": "fsdfds"
}

// Signature 签名
将上面两个对象进行base64编码以后用.进行链接，而后经过HS256算法进行加密就造成了签名，通常须要加上咱们提供的一个密匙，例如secretKey:'name_luffy'
const base64url = require('base64url')

const base64header = base64url(JSON.stringify(header));
const base64payload = base64url(JSON.stringify(payload));
const secretKey = 'name_luffy';
const signature = HS256(`${base64header}.${base64payload}`,secretKey);
// JWT
// 最后就造成了咱们所须要的JWT:
const JWT = base64header + "." + base64payload + "." + signature;
// 它长下面这个样子：
// eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM
复制代码

JWT的工做原理

我从官网JWT.io拿下来的图来展现，就是下面这个过程，说的很详细，此外还有一些细节的东西，好比什么形式存储，放在头部哪里，客户端要存储在哪里等，官网都有比较详细的介绍，你们能够去看看。

先后端如何用这个东西作身份认证

思路

接下来要详细的说如何使用jwt来进行先后端的身份验证了，具体思路以下：

• 用户登陆注册的逻辑不须要身份验证，由于没有用户的身份信息和登陆状态；
• 用户登陆以后后端生成token并返给前端，前端拿到token以后将token缓存在本地，可使localStorage也能够是cookie，以便接下来使用。。
• 其余内容涉及到先后端交互的都须要前端把认证的token信息放在请求头部传给后端
• 后端收到请求先校验token，若是token合法（也就是token正确且没过时），则执行next()，不然直接返回401以及对应的message。

token登陆的具体实现细节

• 后端：express-jwt + jsonwebtoken 首先，安装两个包

yarn add express-jwt jsonwebtoken 
复制代码

以后就是在登陆环节生成token而且把token返回给前端

// /routes/user.js
if (user !== null) {
    // 用户登陆成功事后生成token返给前端
  let token = jwt.sign(tokenObj, secretKey, {
        expiresIn : 60 * 60 * 24 // 受权时效24小时
  });
  res.json({
        success: true,
        message: 'success',
        token: token
  });
} 
复制代码

其次，设置拦截token的中间件，包括token的验证以及错误信息的返回：

// jwt.js,token中间件
const expressJwt = require("express-jwt");
const { secretKey } = require('../constant/constant');
// express-jwt中间件帮咱们自动作了token的验证以及错误处理，因此通常状况下咱们按照格式书写就没问题，其中unless放的就是你想要不检验token的api。
const jwtAuth = expressJwt({secret: secretKey}).unless({path: ["/api/user/login", "/api/user/register"]}); 

module.exports = jwtAuth;
复制代码

// constant.js
// 设置了密码盐值以及token的secretKey
const crypto = require('crypto');

module.exports = {
  MD5_SUFFIX: 'luffyZhou我是一个固定长度的盐值',
  md5: (pwd) => {
    let md5 = crypto.createHash('md5');
    return md5.update(pwd).digest('hex');
  },
  secretKey: 'luffy_1993711_26_jwttoken'
};
复制代码

最后在路由中间件前面放上jwt中间件

// routes/index.js
// 全部请求过来都会进行身份验证
router.use(jwtAuth);
// 路由中间件
router.use((req, res, next) => {
  // 任何路由信息都会执行这里面的语句
  console.log('this is a api request!');
  // 把它交给下一个中间件，注意中间件的注册顺序是按序执行
  next();
});
复制代码

后端逻辑部分所有完成，下面是前端的实现部分。

• 前端： axios拦截器 + localStorage存储token 前端主要作的就是两件事：

第1、把登录成功以后返回的token存在客户端，可使用localStorage也可使用cookie，我看官方推荐使用localStorage，我这边也就用localStorage吧。 第2、每次请求把token放到header头部Authorization字段。

// axios拦截器
// 拦截请求，给全部的请求都带上token
axios.interceptors.request.use(request => {
  const luffy_jwt_token = window.localStorage.getItem('luffy_jwt_token');
  if (luffy_jwt_token) {
    // 此处有坑，下方记录
    request.headers['Authorization'] =`Bearer ${luffy_jwt_token}`;
  }
  return request;
});

// 拦截响应，遇到token不合法则报错
axios.interceptors.response.use(
  response => {
    if (response.data.token) {
      console.log('token:', response.data.token);
      window.localStorage.setItem('luffy_jwt_token', response.data.token);
    }
    return response;
  },
  error => {
    const errRes = error.response;
    if (errRes.status === 401) {
      window.localStorage.removeItem('luffy_jwt_token');
      swal('Auth Error!', `${errRes.data.error.message}, please login!`, 'error')
      .then(() => {
        history.push('/login');
      });
    }
    return Promise.reject(error.message);   // 返回接口返回的错误信息
  });
复制代码

此处有坑，在此记录request.headers['Authorization']必须经过此种形式设置Authorization，不然后端即便收到字段也会出现问题，返回401,request.headers.Authorization或request.headers.authorization能够设置成功，浏览器查看也没有任何问题，可是在后端会报401而且后端一概只能拿到小写的，也就是res.headers.authorization，后端用大写获取会报undefined.

能够看到，登陆成功后，token被存放在localStorage里而且每一次请求都会将token放在头部Authorization字段内。若是咱们把token从localStorage清除，再次访问就会报错。

总结

很是简单的一个小栗子，也没什么技术含量的文章，就当写着玩练习文笔了。代码没有另外放在哪？就在express-react-scaffold上增长的登陆注册和token认证。能够经过/login来访问登录部分逻辑以及token验证功能。 O(∩_∩)O哈哈~