在OAuth 2的背景下,如何处理refresh_token
到期或缺少?{/ p>
我使用JSON Web令牌(JWT)作为access_token
,生命周期很短(20分钟后过期)。据我所知,这意味着我不必存储access_token
,只需验证它(并在内部使用可信信息,如范围)。
但是,我想知道如何实现refresh_token
。在我的研究中,我已经看到谷歌和其他人refresh_token
永远是好的,除非他们被撤销,原因有很多。我认为这意味着系统必须存储所有已发布的刷新令牌,因此可以将它们标记为已撤销。
在存储令牌时,这是一个问题吗?看起来你有一套可能无限的令牌,需要永久存储和访问。
我错过了什么吗?是否有实施刷新令牌的最佳实践?他们应该(或不是)JWT吗?是否也应该存储access_tokens,即使使用JWT?如果是这样,有没有理由让他们超过他们的到期时间? JWT秘密随着时间的推移会发生什么变化呢?
答案 0 :(得分:2)
这是一个很好的问题,而且refresh_tokens通常不会过期,因此应用程序可以生成新的访问令牌而无需要求用户定期重新进行身份验证,
但是,应用程序需要对单个客户端允许的活动刷新令牌数量实施限制,例如:
每个OAuth客户端最多只能有20个活动的refresh_tokens,如果达到该限制,则必须撤销最旧的令牌,并且应该在不拒绝请求的情况下授予新的令牌。
而且如果刷新令牌在某段时间内没有消耗(例如6个月),那么令牌也需要被撤销。
通过这种方式,您可以对refresh_token消费强制执行限制,这就是抓取,这也是Google也在做的事情,