token主动失效的方案

众所周知，在 OAuth2 体系中认证通过后返回的令牌信息分为两大类：不透明令牌（opaque tokens） 和 透明令牌（not opaque tokens）。 不透明令牌 是一种无可读性的令牌，一般来说就是一段普通的 UUID 字符串。使用不透明令牌时资源服务不知道这个令牌是什么，代表谁，需要调用认证服务器校验、获取用户信息。使用不透明令牌采用的是 中心化 的架构。

透明令牌 一般指的是我们常说的 JWT Token，用户信息保存在 JWT 字符串中，资源服务器自己可以解析令牌不再需要去认证服务器校验令牌。使用 JWT 是属于 无状态、去中心化 的架构。 一旦我们选择了使用 JWT，就需要明确一点：在不借助外力的情况下，让 JWT 失效的唯一途径就是等 token 自己过期，无法做到主动让 JWT 失效。非要让 JWT 有主动失效的功能只能借助外力，即在服务端存储 JWT 的状态，在请求时添加判断逻辑，这个与 JWT 的无状态化、去中心化特性是矛盾的。但是，既然选择了 JWT 这条路，那就只能接受这个现实。

#数据库存储token

认证通过时，把 JWT 存到数据库的token表中。注销时，将表中的token置为无效状态。请求资源添加判断 JWT 在token表中是否存在，不存在拒绝访问。定期清除token，假设token有效期为一个月，可以对token表按月分表，按期清除一个月之前的token表。

redis存储token

在服务端存储 JWT 的状态，也可以使用 Redis 等高速缓存。而存储 JWT 状态又分为两种方案

1、白名单机制

认证通过时，把 JWT 存到 Redis 中。注销时，从缓存移除 JWT。请求资源添加判断 JWT 在缓存中是否存在，不存在拒绝访问。这种方式和 cookie/session 机制中的会话失效删除 session 基本一致。

2、黑名单机制

注销登录时，缓存 JWT 至 Redis，且缓存有效时间设置为 JWT 的有效期，请求资源时判断是否存在缓存的黑名单中，存在则拒绝访问。

白名单和黑名单的实现逻辑差不多，黑名单不需每次登录都将 JWT 缓存，仅仅在某些特殊场景下需要缓存 JWT，给服务器带来的压力要远远小于白名单的方式。

我更倾向于使用黑名单机制，有两个原因：

一是会大大节省 Redis 的存储空间，我们甚至都不需要存储完整的 jwt，只需要存储 jwt 中的唯一 id jti 即可。