今天记录一下学习到的后端接口认证的知识，JWT 技术。

前言

我的小项目需要使用一种接口认证机制，为了尽量减小服务器端的资源压力，我选择了近年来非常火热的JWT技术。

简介

什么是JWT?

JSON Web Tokens - jwt.io

在其官网的首页上有一段非常显眼的介绍：“JSON Web Token 是一个开放的行业标准（RFC 7519），可以在两方之间安全传输信息”。

如下是一个经过编码的token：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

请忽视换行符，token由三个部分组成并且使用.号分隔：

1. 头部
2. 载荷对象
3. 验证签名

让我们通过一张图片来理解这个过程：


上述例子中的：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9就是头部数据经过base64编码后的结果。eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ则是载体对象经过base64编码后的结果，而SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c则是通过某种算法对头部 base64 编码+.+载荷对象 base64 编码和秘钥进行加密后的结果。

JWT 的优缺点

优点

• JWT 具有较好的扩展性，且相对于传统的 Session 方案有不占服务器资源的优势

• JWT 的载荷对象中可以存储信息（加密或不加密可视情况而定）

缺点

• 易滥用：当载荷对象中存储的信息过多的时候，token将会变得非常冗长，所以需要开发者进行控制，避免滥用于数据交换
• 载荷和头部对象可以直接通过 base64 进行解码得到明文信息（当然开发者可以进行额外的加密控制，或者使用 https 技术防止 token 泄露）
• 不支持撤销（可以通过增加服务器端缓存或白名单机制来弥补，但同时也增加了资源消耗）

适用场景

• 安全要求不高的认证场景
• 短期或一次性认证需求

Koa 和 Jwt

我的个人项目使用了Koa框架开发后端接口应用，为了使用JWT的特性我需要安装以下两个包：

• koa-jwt
• jsonwebtoken

koa-jwt中间件让我们能够设置使用jwt来保护哪些路由，并且将请求头中的token数据解析出来，扩展到ctx上下文中。

显然，我们可以将注册和登录的接口作为白名单，直接提供给所有用户使用，当用户注册或登录成功的时候，服务端通过jsonwebtoken创建一个token并返回给客户端。

此时，客户端可以将之保存在localstorage中，并且使用axios之类的库对请求进行拦截，设置拦截器将token放在请求头上面，形如：

Authorization: Bearer <token>	

此时，token保存在客户端上，服务端可以通过秘钥和加密算法就能解析到token的信息。

Koa-jwt 和 jsonwebtoken 的使用方法建议阅读文档。

网上有一种refresh token的说法，即设置一个访问周期，当用户持续访问服务器时根据访问周期来提供新token来替换旧token，从而让保持有效期内访问的用户延长需要重新登录的时间。

显然这种机制需要设置一个合适的token过期时间和刷新周期，被替换的token在某些时间段依然可以访问服务器。

在不同的场合下选择不同的技术才是解决问题的关键！

参考

• JSON Web Tokens - jwt.io
• JSON Web Token Introduction - jwt.io