koa-jwt如何使用

Question

我现在想做一个用户认证登陆的功能。

前端通过登陆调用接口，使用koa-jwt获取token，返回给前端后存到cookie里。

然后前端的所有ajax请求会将这个token放在header里传给后端。

现在后端验证这里我不清楚该怎么做。

后端现在能通过headers获取前端传过来的token。但是应该怎么判断当前token是否是失效呢？

我的想法是通过

if (!this.request.headers.token) {this.throw(401, 'Authorization required');}

来判断。但是好像不能判断token是否失效。

请问一下koa-jwt该如何使用呀？网上的例子好像比较少。不是太懂怎么用。

Answer 1

1.首先你要知道koa-jwt的功能，目前只提供了decode， sign和verify的功能，你说的判断token过期koa-jwt module没有专门提供函数来验证。

2.那如何判断token过期了呢？ 先简单和你介绍一下jwt，然后再教你如何判断过期。

2.1 jwt简介

JSON Web Token(jwt) 在网页中，许多操作都需要验证用户权限，判断用户是否登陆等。一般有两种实现方式： 一种是通过session和cookie； 另一种就是用鉴权token。利用token来鉴权主要有以下两个优势。

• 服务端不需要请求DB来获取用户信息，因为用户信息已经存在token里面。

• token鉴权的方式对移动端和PC端同样适用，服务端不需要维护两套鉴权机制。

一个标准的jwt是由3部分组成 <header>， <payload> 和 <signature>

• Header: base64编码的json object， 包括使用的加密算法等。

• Payload: base64编码的json object， 存储用户相关的信息。

• Signature: 根据Header，PayloadA 和一个密钥(只有服务端知道)，并利用Header中指定的加密算法，生成的一个签名串。

2.2 如何判断失效

判断token过期有许多方法，我这里列出几种供你选择

• jwt 提供了过期参数设置，在签发token的时候(koa-jwt调用sign的时候)，在Payload里面设置exp属性，这是jwt提供的Registered Claims（保留声明）， 记住一定要比当前时间大才行，如设置成当前时间之后10分钟过期

{
  exp: Date.now()+10*60*1000,
}

然后你可以持久化存储到你的localstorage， sessionStorage或者cookie里面，这个token通过请求传到服务端，验证(调用koa-jwt的verify的时候)的时候就会报TokenExpiredError

Thrown error if the token is expired.

Error object:

- name: 'TokenExpiredError'
- message: 'jwt expired'
- expiredAt: [ExpDate]

• 服务端生成token之后，你可以在请求的返回里面，把这个token存到cookie(或者sessionStorage)里面， 然后设置这个cookie的过期时间expire， 这样下次请求你在你的请求的header或者body里面拿不到token的时候就知道token过期了(和你提供的代码类似，不过记得设置存储token的这个cookie的过期时间)。

• 自定义类似exp的属性，因为exp是保留属性，所以你可以设置一个origin-iat上次颁发的时间，然后持久化存储，之后解出token之后，判断当前时间和origin-iat的时间差有没有达到你的过期时间，达到了就重新要求鉴权，重新颁发token， 伪代码如下

var profile = jwt.verify(req.header.token || req.body.token, secret);

  // if more than 7 days old, force login
  if (Date().now() - profile.original_iat  > 7 * 24 * 60 * 60 * 1000) { // iat == issued at
    return res.status(401).json({ isError: true, error: { message: 'Access Forbidden'}}); // re-logging
  }

几种方式的区别是： 第一种和第三种方式通过请求可以一直取到token，但是token可能是过期的。 第二种方式是通过请求可能获取不到token。 你自己可以根据你的业务需求做出合适的选择。

附： JSON Web Token Specification RFC 7519