基于 JWT + Refresh Token 的用户认证明践

HTTP 是一个无状态的协议，一次请求结束后，下次在发送服务器就不知道这个请求是谁发来的了（同一个 IP 不表明同一个用户），在 Web 应用中，用户的认证和鉴权是很是重要的一环，实践中有多种可用方案，而且各有千秋。

基于 Session 的会话管理

在 Web 应用发展的初期，大部分采用基于 Session 的会话管理方式，逻辑以下。

• 客户端使用用户名密码进行认证
• 服务端生成并存储 Session，将 SessionID 经过 Cookie 返回给客户端
• 客户端访问须要认证的接口时在 Cookie 中携带 SessionID
• 服务端经过 SessionID 查找 Session 并进行鉴权，返回给客户端须要的数据

基于 Session 的方式存在多种问题。

• 服务端须要存储 Session，而且因为 Session 须要常常快速查找，一般存储在内存或内存数据库中，同时在线用户较多时须要占用大量的服务器资源。
• 当须要扩展时，建立 Session 的服务器可能不是验证 Session 的服务器，因此还须要将全部 Session 单独存储并共享。
• 因为客户端使用 Cookie 存储 SessionID，在跨域场景下须要进行兼容性处理，同时这种方式也难以防范 CSRF 攻击。

基于 Token 的会话管理

鉴于基于 Session 的会话管理方式存在上述多个缺点，无状态的基于 Token 的会话管理方式诞生了，所谓无状态，就是服务端再也不存储信息，甚至是再也不存储 Session，逻辑以下。

• 客户端使用用户名密码进行认证
• 服务端验证用户名密码，经过后生成 Token 返回给客户端
• 客户端保存 Token，访问须要认证的接口时在 URL 参数或 HTTP Header 中加入 Token
• 服务端经过解码 Token 进行鉴权，返回给客户端须要的数据

基于 Token 的会话管理方式有效解决了基于 Session 的会话管理方式带来的问题。

• 服务端不须要存储和用户鉴权有关的信息，鉴权信息会被加密到 Token 中，服务端只须要读取 Token 中包含的鉴权信息便可
• 避免了共享 Session 致使的不易扩展问题
• 不须要依赖 Cookie，有效避免 Cookie 带来的 CSRF 攻击问题
• 使用 CORS 能够快速解决跨域问题

JWT 介绍

JWT 是 JSON Web Token 的缩写，JWT 自己没有定义任何技术实现，它只是定义了一种基于 Token 的会话管理的规则，涵盖 Token 须要包含的标准内容和 Token 的生成过程。

一个 JWT Token 长这样。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1NDQ1MTE3NDMsImp0aSI6IjYxYmVmNjkyLTE4M2ItNGYxYy1hZjE1LWUwMDM0MTczNzkxOSJ9.CZzB2-JI1oPRFxNMaoFz9-9cKGTYVXkOC2INMoEYNNA
复制代码

仔细辨别会发现它由 A.B.C 三部分组成，这三部分依次是头部（Header）、负载（Payload）、签名（Signature），头部和负载以 JSON 形式存在，这就是 JWT 中的 JSON，三部分的内容都分别单独通过了 Base64 编码，以 . 拼接成一个 JWT Token。

JWT 的 Header 中存储了所使用的加密算法和 Token 类型。

{
  "alg": "HS256",
  "typ": "JWT"
}
复制代码

Payload 是负载，JWT 规范规定了一些字段，并推荐使用，开发者也能够本身指定字段和内容，例以下面的内容。

{
  username: 'yage',
  email: 'sa@simpleapples.com',
  role: 'user',
  exp: 1544602234
}
复制代码

须要注意的是，Payload的内容只通过了 Base64 编码，对客户端来讲当于明文存储，因此不要放置敏感信息。

Signature 部分用来验证 JWT Token 是否被篡改，因此这部分会使用一个 Secret 将前两部分加密，逻辑以下。

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
复制代码

JWT 优点 & 问题

JWT 拥有基于 Token 的会话管理方式所拥有的一切优点，不依赖 Cookie，使得其能够防止 CSRF 攻击，也能在禁用 Cookie 的浏览器环境中正常运行。

而 JWT 的最大优点是服务端再也不须要存储 Session，使得服务端认证鉴权业务能够方便扩展，避免存储 Session 所须要引入的 Redis 等组件，下降了系统架构复杂度。但这也是 JWT 最大的劣势，因为有效期存储在 Token 中，JWT Token 一旦签发，就会在有效期内一直可用，没法在服务端废止，当用户进行登出操做，只能依赖客户端删除掉本地存储的 JWT Token，若是须要禁用用户，单纯使用 JWT 就没法作到了。

基于 JWT 的实践

既然 JWT 依然存在诸多问题，甚至没法知足一些业务上的需求，可是咱们依然能够基于 JWT 在实践中进行一些改进，来造成一个折中的方案，毕竟，在用户会话管理场景下，没有银弹。

前面讲的 Token，都是 Access Token，也就是访问资源接口时所须要的 Token，还有另一种 Token，Refresh Token，一般状况下，Refresh Token 的有效期会比较长，而 Access Token 的有效期比较短，当 Access Token 因为过时而失效时，使用 Refresh Token 就能够获取到新的 Access Token，若是 Refresh Token 也失效了，用户就只能从新登陆了。

在 JWT 的实践中，引入 Refresh Token，将会话管理流程改进以下。

• 客户端使用用户名密码进行认证
• 服务端生成有效时间较短的 Access Token（例如 10 分钟），和有效时间较长的 Refresh Token（例如 7 天）
• 客户端访问须要认证的接口时，携带 Access Token
• 若是 Access Token 没有过时，服务端鉴权后返回给客户端须要的数据
• 若是携带 Access Token 访问须要认证的接口时鉴权失败（例如返回 401 错误），则客户端使用 Refresh Token 向刷新接口申请新的 Access Token
• 若是 Refresh Token 没有过时，服务端向客户端下发新的 Access Token
• 客户端使用新的 Access Token 访问须要认证的接口

将生成的 Refresh Token 以及过时时间存储在服务端的数据库中，因为 Refresh Token 不会在客户端请求业务接口时验证，只有在申请新的 Access Token 时才会验证，因此将 Refresh Token 存储在数据库中，不会对业务接口的响应时间形成影响，也不须要像 Session 同样一直保持在内存中以应对大量的请求。

上述的架构，提供了服务端禁用用户 Token 的方式，当用户须要登出或禁用用户时，只须要将服务端的 Refresh Token 禁用或删除，用户就会在 Access Token 过时后，因为没法获取到新的 Access Token 而再也没法访问须要认证的接口。这样的方式虽然会有必定的窗口期（取决于 Access Token 的失效时间），可是结合用户登出时客户端删除 Access Token 的操做，基本上能够适应常规状况下对用户认证鉴权的精度要求。

总结

JWT 的使用，提升了开发者开发用户认证鉴权功能的效率，下降了系统架构复杂度，避免了大量的数据库和缓存查询，下降了业务接口的响应延迟。然而 JWT 的这些优势也增长了 Token 管理上的难度，经过引入 Refresh Token，既能继续使用 JWT 所带来的优点，又能使得 Token 管理的精度符合业务的需求。

关注公众号【Python私房菜】