新方案
如何做到防止伪造，就是说即使算法泄露，服务端也能识别出来。要做到这一点，服务端就要缓存
token 的存根，当请求到达时，比较请求中的 token 和服务端同一个用户的 token 存根是否匹配。如
果匹配，验证通过；如果不匹配，表示 token 是伪造的；或者账号已经在另外的设备上登录，从而
挤掉了当前的 token，让用户重新登录。所以这个方案，顺便解决了第 3 个问题。
服务端缓存 token，可以使用 redis，以 userId 为 key，以详细用户数据和 token 为 value。收到请求
时，需要从 token 中解析出 userId，这样才能进一步根据 userId 从缓存中查数据。但是有一个问题
是如何判断 token 的有效期。
在前一篇文章中，从 token 解析出 token 的创建时间，然后加上有效期，跟系统的当前时间进行比
较。如果大于当前时间，表示有效，否则表示过期。但是既然服务端已经把 token 放入缓存了，可
以直接使用缓存的有效期来表示 token 的有效期。一句话：如果根据 token 解析出来的 userId 从缓
存中查不出来什么，表示 token 已经过期。
参考了微信登录，他们是基于 OAuth2.0 标准来做的。当时也对 OAuth2.0 进行了调研，结果是它是
用来为第三方请求资源时提供的一种授权和身份验证机制。简单来说，它的时序图是下面的样子：
OAuth2-简化图
因为我们需要维护自己的用户体系，而且只有一个系统，没有必要搞这么多事，所以最后决定放弃
OAuth2.0，自己实现身份验证机制，这其实也是参考了之前的一个项目的做法。
微信登录中提到了两个 token：access_token 和 refresh_token。access_token 用来请求业务的时候进行
身份验证。当 access_token 过期时，可以使用 refresh_token 来刷新 token（即请求新的 token），直
到 refresh_token 也过期了，那么第三方应用需要重新请求授权。access_token 有较短的有效期，一
般 2 个小时，refresh_token 有效期较长，有 30 天。
评论0