基于Refresh Tokens 的 Session Authe

更新的版本 发布在 HackFrog 账号。

在职业蛙CareerFrog，我们的技术主要是用于完善和发展业务，我们的核心系统是一个结合了CRM和CMS的复杂并且高效的业务系统。当我们的业务系统发展到一定阶段，简单的 Token Auth 方案已经不能满足系统扩展以及安全性需求，在权衡了几种较好的 Auth 方案，结合业务需求，并且在保证“快速迭代”的前提下，我们最终使用了一个基于 Refresh Token 的 Session Authentication 方案。其图示如下，细节将在文末方案详述一节展开。

图1. refresh-token-based session authentication overview

JWT Token Auth 方案

Authentication 是每一个系统必不可少的一个逻辑成分，我们的核心业务系统（以下简称master系统）自然从一开就有一套使用 JWT 的 Token Auth 方案。这个方案非常简洁并且有效，其基本思路如下：

图片来源：https://medium.com/vandium-software/5-easy-steps-to-understanding-json-web-tokens-jwt-1164c0adfcec

JWT（JSON Web Tokens）的实现细节可以参考 Mikey Stecky-Efantis的这篇文章或者官方介绍，不关心这些细节的可以直接前往查看 Auth0的 jsonwebtoken 的github介绍。

方案特点

• 易用性 Usability：数据存储在客户端，服务端仅需要对数据进行加密和解密即可。
• 可扩展性 Scalability：JWT 简单来说就是加密的JSON数据，JWT协议本身对这里的数据几乎没有任何格式或大小限制。在我们使用的时候，可以根据系统要求随时修改token的内容结构。
• 安全性 Security：HttpOnly 一定程度上降低了XSRF攻击的可能性。

需求和问题

我们的系统一开始对于用户数据的使用相对有限，所以轻量化的Token方案完全可以满足需求。但随着业务需求积累，系统的复杂度逐渐提升，Token方案的不足逐渐暴露出来，其中最主要的问题有两个：

1. 某些服务需要一些用户相对隐私的信息，将这些数据存储在Token中显然是不负责任的。
2. 出于安全性考虑，在特定情况下（如用户修改重要信息后）我们需要对用户的登录状态进行控制，Token是做不到的。

当这些问题的重要性达到一定程度的时候，我们不得不开始寻找改进甚至替代方案。

替代方案探寻

1. Session 方案

因为需要控制用户登录状态，我们自然首先会想到使用服务器session。 Session 本质上是用于存储用户访问相关数据的key-value数据结构。用户每一次登录后服务器会生成一个session， 并将 session ID 保存到客户端，客户端以 session ID 为凭证来进行后面的一系列 http 请求。

[@eloone这篇关于 web session 的文章](http://machinesaredigging.com/2013/10/29/how-does-a-web-session-work/)很好得解释了session的一些基础

Session 方案的特点

• 性能 FastAccess：通常 session 会存储在内存之类的高速存储中，相比于SQL数据库查询或者Token解析，获取和更新 session 速度会快很多。
• 服务端控制 ServerInvalidation：所有的用户信息都存储在后端的 session 数据中， 服务器可以主动更改
  session 或者使 session 过期。

2. Refresh Token 方案

Refresh Token 指的是 OAuth 2.0 所提出的一种Token验证模式，其中会用到两种Token： Access Token 和 Refresh Token。Access Token用于向 Api Service 发送请求时提供身份和权限凭证，它是具有短时效性的特点。 Refresh Token 用于向 Authentication Service 请求新的 Access Token， 从而保持用户的登录状态，它通常是长久保存在客户端的。

关于 Refresh Token 的介绍可以查看这篇Understanding Refresh Tokens。

图片来源：https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/

方案特点

• 快速验证 FasterChecks：Access Token 自身就包含了验证信息，Api Service 不需要再调用 Auth Service 来验证用户登录状态及获取用户信息。
• ** 安全性 ShortAttackWindow**：Access Token 的短时效性极大地缩短了MITM攻击的窗口，提升了安全性。

方案选择

在短时间内做了大量的research之后，基本上能找到的解决方案都是基于以上三种：Token，Session 和 Refresh Token。在选择的时候遇到了难题：基本的Token方案的缺陷已经决定了我们不能再继续使用，使用Session方案的似乎非常符合专业性了，但Refresh Token机制看起来也很fancy。但问题是，Implementation is Everything，每一种方案实现都有它的优缺点。

对于使用什么样的方案我们迟迟不能决定，这个时候我们意识到，当我们开始钻牛角尖去找“最完美的方案”的时候，我们已经失去了机动性。于是我们回到我们的问题和需求上去：

问题和需求

• 信息安全和隐私保障
• 用户信息绑定
• 快速验证

回到这些点上，我们仅解决这些问题。那么，由于安全性需求，Refresh Token 是最好的选择，又因为需要绑定信息涉及用户隐私，则必须有服务器 Session 存储，同时Session有着良好的性能。综合以上，我们提出一个调整的方案：以 Refresh Token 为基础来保障 Authentication，同时用Session ID 来替换 Access Token，做到信息安全。

方案详述

最终方案图示如图1（见摘要部分），其中包含四个主要组成：Client客户端（e.g. 浏览器），Auth Service，Api Service 以及 这两个 Service 共用的 Session 数据。这些端之间的交互主要分以下五点（同图示序号）：

1. 用户登录：用户 Client 端使用账号密码登录，登陆成功 Auth Service 返回 Refresh Token；
2. 定时获取session_id：Client 定时在 session_id 失效前向 Auth Service 请求新的session_id；
   注：1，2 中使用Auth Service 应使用Https cookie保证安全性
3. 资源请求：用户 Client 端向 Api Service 发起请求，并携带 session_id；
4. Auth Middleware：Api Service 收到请求时，第一步通过 Auth Middleware 来验证
   session_id 并绑定用户信息；
5. Api 返回：Api Service 处理请求并返回结果；

。。。maybe more specific here

总结

在此次 Auth 方案改进的进程中，我们进行了比较多的探索，各种新的旧的方案都有所尝试，甚至使用过一些有明显缺陷的方案，在探索过程中获得了很多收获，让我们看到一些不同的思考问题的方式。需要注意的是，在大量的research中，我们会接触到大量各有优缺点的方案和不同的声音，在这之中很容易迷失方向，最终舍本逐末。对于我们以业务为核心的创业公司来说，最重要的还是明确需求，快速提出解决方案，同时留下改进余地。
最后还需要提出的是，我们的方案绝对不是完美的，只是就我们现有的系统架构和需求来说，相对好的方案。以上提出的一点 research 结果，供大家参考，具体可见参考文章。

参考文章：

1. 5 Easy Steps to Understanding JSON Web Tokens (JWT)
2. How does a web session work
3. Stop using JWT for sessions
4. Refresh Tokens: When to Use Them and How They Interact with JWTs