关于分布式系统中jwt token主动过期的方案总结

1. 引言

在许多安全策略中，Token 过期管理是一个非常重要的环节。Token 是用于验证用户身份和授权的凭证，如果长时间有效，可能会增加安全风险。因此，实现一个合理的 Token 主动过期方案至关重要。

jwt token是分布式系统现在较为流行的解决单点登录的手段。但在分布式系统中使token主动过期是一件比较让人头疼的问题，因为jwt在设计之初过期的唯一方式就是让token到时间后自动过期。
当我们想要让某些token主动过期时，比如踢用户下线或封禁用户等场景，要依托jwt自己的过期时间到了自动过期显然会让系统承担比较大的安全风险，为此我们需要有一种手段能够使token主动过期。

2. token 过期方案的重要性

1. 防止潜在的安全威胁：如果 Token 无限期或太长时间有效，它可能被恶意用户获取并利用。设置合理的过期时间可以降低这种风险。
2. 维护数据的完整性：长时间有效的 Token 可能存在被篡改的风险，设置主动过期可以减少这种风险。
3. 保护用户隐私：过期的 Token 无法用于追踪用户活动，从而保护用户隐私。

3. token 主动过期的实现方案

• 白名单

认证服务记录所有的已颁发的token到redis或其他集中的token管理服务中，当要主动过期token时，只需将token中管理服务中删除。其他服务需要校验token有效性时，，只需去token管理服务中查询即可，token存在即认为有效。

优点：能集中式管理所有token，实现简单，服务间结构清晰。
缺点：需要存储所有已颁发的token到token管理服务中，如果token很多对管理服务的存储和查询能力要求很高。

• 黑名单

认证服务正常颁发jwt token给其他服务，当认证服务需要主动过期token时，将需要过期的token添加到token管理服务中。其他服务校验token的有效性时，需要解析token中的是否过期，当未过期时，还需去token管理服务中查询该token是否有效，如果在token管理服务中存在，则认为该token无效了。

优点：token管理服务无需存储大量的有效token，可以节省存储空间
缺点：当其他服务需要验证token有效性时，不但需要解析token，还需要去token管理服务中查询token的有效性，会造成校验性能下降，可能会给系统的tps/qps带来影响。

• 短过期时间

给token设定很短的过期时间，比如半个小时，让需要认证的实例每隔半个小时就来重新认证，用旧token换取新token。当需要主动过期某个token时，认证服务先把token记录下来，当认证实体用旧token换取新token时直接拒绝刷新即可。为了减小用户每次重新认证造成体验不好可以配合refresh token进行无感的token刷新。

优点：token管理服务无需存储任何token，其他服务也无需去token管理服务中查询token的有效性。
缺点：主动过期可能不会立即生效，如果旧token不到过期时间，则需要过期的token在系统中依旧可以使用。

4. 总结

jwt token本是为了解决服务间无状态调用确认调用身份合法性的问题出现的解决方案。其设计是为了去中心化、无状态的设计，无需一个统一的token管理服务。为了解决无法主动过期token的问题，就需要人为引入状态对token进行管理，需要服务端记录某些token，这又违背了jwt token的设计初衷。

在实际生产中如果有类似需求，我们可以根据实际情况结合每种解决方案的优缺点来选择解决方案。我个人比较推荐黑名单的解决方案，因为其对存储的要求适中，且可以实时使token主动过期生效，提高了系统的安全性。

5. 思考jwt token的应用场景

当我们需要解决单点登录问题，且无需考虑颁发出的token的管理问题时，使用jwt是一种很好的解决方案。比如内网系统的单点登录，或者需要短期有效的token比如付款场景或者审批业务场景，都是需要认证并且需要在较短时间内完成的业务。
但是当我们需要主动控制需要颁发的token时，那么jwt就不太适合了，不如使用session+分布式缓存来处理控制认证状态。