在职业蛙CareerFrog，我们的技术主要是用于完善和发展业务，我们的核心系统是一个结合了CRM和CMS的复杂并且高效的业务系统。当我们的业务系统发展到一定阶段，简单的 Token Auth 方案已经不能满足系统扩展以及安全性需求，在权衡了几种较好的 Auth 方案，结合业务需求，并且在保证“快速迭代”的前提下，我们最终使用了一个基于 Refresh Token 的 Session Authentication 方案。其图示如下，细节将在文末方案详述一节展开。
初始的 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：JWT 简单来说就是加密的字符串，加密解密方法都身份简单直接。
- 扩展性 Scalability：Token数据存储在客户端，服务端仅需要对数据进行加密和解密即可。在我们使用的时候，可以根据系统要求随时修改token的内容结构。
- 安全性 Security：HttpOnly 一定程度上降低了XSRF攻击的可能性。
需求和问题
我们的系统一开始对于用户数据的使用相对有限，所以轻量化的Token方案完全可以满足需求。但随着业务需求积累，系统的复杂度逐渐提升，Token方案的不足逐渐暴露出来，其中最主要的问题有两个：
- 某些服务需要一些用户相对隐私的信息，将这些数据存储在Token中显然是不负责任的。
- 出于安全性考虑，在特定情况下（如用户修改重要信息后）我们需要对用户的登录状态进行控制，Token是做不到的。
当这些问题的重要性达到一定程度的时候，我们不得不开始寻找改进甚至替代方案。
替代方案探寻
1. Session 方案
因为需要控制用户登录状态，我们自然首先会想到使用服务器session。 Session 本质上是用于存储用户访问相关数据的key-value数据结构。用户每一次登录后服务器会生成一个session， 并将 session ID 保存到客户端，客户端以 session ID 为凭证来进行后面的一系列 http 请求。
@eloone这篇关于 web session 的文章很好得解释了session的一些基础
Session 方案的特点
- 性能 FastAccess：通常 session 会存储在内存之类的高速存储中，相比于SQL数据库查询或者Token解析，获取和更新 session 速度会快很多。
- 服务端控制 ServerInvalidation：所有的用户信息都存储在后端的 session 数据中， 服务器可以主动更改一个特定的 session 或者使其失效(invalidation)。
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 的 cookie 通常是在使用 HTTPS 的Auth服务域名下的。
关于 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 的短时效性极大地缩短Man In The Middle(MITM)攻击的窗口，提升了安全性。
方案选择
在短时间内做了大量的research之后，基本上能找到的解决方案都是基于以上三种：Token，Session 和 Refresh Token。在选择的时候遇到了难题：基本的Token方案的缺陷已经决定了我们不能再继续使用，使用Session方案的似乎非常符合专业性了，但Refresh Token机制看起来也很fancy。但问题是，Implementation is Everything，每一种方案实现都有它的优缺点。
对于使用什么样的方案我们迟迟不能决定，这个时候我们意识到，当我们开始钻牛角尖去找“最完美的方案”的时候，我们已经失去了机动性。于是我们回到我们的问题和需求上去：
核心问题及需求
- Security: 信息安全和隐私保障
- Session Data: 用户信息绑定
- Performance: 快速验证
回到这些点上，我们仅解决这些问题。那么，由于安全性需求，Refresh Token 是最好的选择，又因为需要绑定信息涉及用户隐私，则必须有服务器 Session 存储，同时Session有着良好的性能。综合以上，我们提出一个调整的方案：以 Session 为基础来做服务器 session 信息存储和管理，同时引入 Refresh Token 来作为 ‘Refresh Session’ 来定期更新 Session ID 来提升安全性。
方案详述
最终方案图示如下图，其中包含四个主要组成：Client客户端（e.g. 浏览器），Auth Service，Api Service 以及 这两个 Service 共用的 Session 数据。这些端之间的交互主要分以下五点（同图示序号）：
- 用户登录：用户 Client 端使用账号密码登录，登陆成功 Auth Service 返回 Refresh Token；
- 定时获取session_id：Client 定时在 session_id 失效前向 Auth Service 请求新的session_id；
注：1，2 中使用Auth Service 应使用Https cookie保证安全性 - 资源请求：用户 Client 端向 Api Service 发起请求，并携带 session_id；
- Auth Middleware：Api Service 收到请求时，第一步通过 Auth Middleware 来验证
session_id 并绑定用户信息； - Api 返回：Api Service 处理请求并返回结果；
最终方案图解
总结
在此次 Auth 方案改进的进程中，我们进行了比较多的探索，各种新的旧的方案都有所尝试，甚至使用过一些有明显缺陷的方案，在探索过程中获得了很多收获，让我们看到一些不同的思考问题的方式。需要注意的是，在大量的research中，我们会接触到大量各有优缺点的方案和不同的声音，在这之中很容易迷失方向，最终舍本逐末。对于我们以业务为核心的创业公司来说，最重要的还是明确需求，快速提出解决方案，同时留下改进余地。
最后还需要提出的是，我们的方案绝对不是完美的，只是就我们现有的系统架构和需求来说，相对好的方案。以上提出的一点
research 结果，供大家参考，具体可见参考文章。
