使用token做认证授权时,会发现注销登录等场景下token还有效。因为token不同于Session认证方式——用户退出登录时,服务端删除对应的Session记录即可。如果不引入其他机制,则退出登录时,token仍有效,即仍是登录状态,直到token有效时间到。
下面介绍几个方案:
1、直接从客户端移除token
显然,这对服务端的安全性没有任何帮助,但是这的确使客户端退出登录,而且通过删除token来阻止攻击者,因为他们必须在注销之前窃取token。
2、创建token黑名单
可以维护一份token黑名单,将无效的且未到过期时间的token存储在内,每次传入的请求都需对比token黑名单。不过这种方式舍弃了token的优势,因为每个请求都需要访问数据库。不过,此方案的存储空间会很小,因为你只需要存储在注销和到期时间之间的token。
3、缩短token到期时间并经常轮换
将token到期时间保持在足够短的时间间隔内,并让正在运行的客户端跟踪并在必要时请求更新,那么将有效地完成用户注销登录。但是,会导致用户登录状态不会被持久记录,而且需要用户经常登录。
4、修改密钥(Secret)
我们为每个用户都创建一个专属密钥,如果我们想让某个 token 失效,我们直接修改对应用户的密钥即可。但是,这样相比于前两种引入内存数据库带来了危害更大,
比如:
- 如果服务是分布式的,则每次发出新的 token 时都必须在多台机器同步密钥。为此,你需要将密钥存储在数据库或其他外部服务中,这样和 Session 认证就没太大区别了。
- 如果用户同时在两个浏览器打开系统,或者在手机端也打开了系统,如果它从一个地方将账号退出,那么其他地方都要重新进行登录,这是不可取的。
在OAuth认证中,token的管理是关键。当用户注销登录时,直接删除客户端的token仅保障客户端安全,但服务端仍需应对token有效性。方案包括:1) 创建token黑名单,虽然增加数据库查询但能有效管理;2) 缩短token有效期并频繁刷新,牺牲用户体验换取安全;3) 修改密钥可能导致多设备登录同步问题。这些策略权衡了安全与用户体验。
785

被折叠的 条评论
为什么被折叠?



