在django-rest-framework-jwt中缓存Auth0认证结果是否存在安全问题

这个方案本身是合理的，对于请求密集的场景，短时间缓存身份验证结果确实可以大幅降低Auth0远程验证带来的延迟损耗，10秒的缓存时长也属于比较保守的取值，性能收益很明显。

• 令牌失效滞后问题：如果用户主动登出、令牌被泄漏后管理员主动吊销、或者令牌本身已经过期，在缓存的10秒有效期内，这些已经失效的令牌依然可以通过服务端的身份验证，等于放大了令牌泄漏的风险，也不符合登出立即生效的产品预期。
• 权限更新不及时：如果用户的角色、权限在Auth0侧发生了变更，缓存有效期内服务端依然会使用旧的身份payload做权限判断，会出现权限调整不生效的时间差，比如用户的管理员权限被回收后10秒内依然可以操作后台接口。
• 缓存本身的安全风险：
  1. 你当前使用MD5算法生成缓存key，MD5存在已知的哈希碰撞缺陷，极端情况下攻击者可以构造特殊的请求头碰撞到已有的缓存key，越权拿到其他用户的身份验证结果
  2. 如果使用的是共享缓存（比如多实例共用的Redis），一旦缓存被攻击者拖库，不需要破解JWT就可以直接拿到大量有效用户的身份元组，伪造身份发起请求
• 缓存击穿风险：如果缓存服务宕机、或者大量新令牌同时发起请求，所有验证流量都会直接打到Auth0，很容易触发Auth0的速率限制，导致正常请求的身份验证失败。

1. 优先考虑本地JWT验签替换远程验证：JWT本身是支持本地验签的，你只需要把Auth0平台的签名公钥提前下载到Django服务端本地，直接用公钥验证JWT的签名有效性，整个验签过程只需要几毫秒，不需要远程调用Auth0，也没有缓存带来的安全问题，是性能和安全平衡的最优解。
2. 如果确实需要保留缓存方案，建议做如下调整：
   • 把缓存时长压缩到3~5秒，进一步缩小安全风险的时间窗口
   • 替换MD5为SHA256算法生成缓存key，避免哈希碰撞风险
   • 增加令牌黑名单机制，对于主动吊销的令牌，直接写入缓存黑名单，验证时优先判断令牌是否在黑名单中，存在则直接拒绝访问
   • 增加Auth0请求的限流降级策略，缓存击穿时避免把Auth0的接口打挂，影响全站可用性

内容的提问来源于stack exchange，提问作者user1383029