在 OAuth 2 的上下文中，如何处理refresh_token过期，还是缺少？
我使用 JSON Web 令牌 (JWT) 作为access_token生命周期较短（20 分钟后过期）。据我了解，这意味着我不必存储access_token，仅验证它（并使用内部的可信信息，例如范围）。
不过，我想知道如何实现refresh_tokens。在我的研究中，我发现谷歌和其他公司已经refresh_token除非出于多种原因被撤销，否则它们将永远有效。我认为这意味着系统必须存储所有发出的刷新令牌，这样它们就可以被标记为已撤销。
当涉及到代币的存储时，这是一个问题吗？似乎您有一组潜在的无限令牌需要永久存储和访问。
我错过了什么吗？是否有实施刷新令牌的最佳实践？它们应该是（还是不是）JWT？即使使用 JWT，是否也应该存储 access_token？如果是这样，是否有任何理由让它们超过有效期？ JWT 秘密会随着时间的推移而变化吗？
这是一个很好的问题，刷新令牌通常不会过期，因此应用程序可以生成新的访问令牌，而无需要求用户定期重新进行身份验证，
但应用程序需要对单个客户端允许的活动刷新令牌数量实施限制，例如：
每个 OAuth 客户端最多只能有 20 个活动的刷新令牌，如果达到该限制，则必须撤销最旧的令牌，并应在不拒绝请求的情况下授予新的令牌。
而且，如果刷新令牌在一段时间内（例如 6 个月）没有被消耗，那么该令牌也需要被撤销。
通过这种方式，你可以对refresh_token的消耗进行限制，这里有一个问题，谷歌也是这样做的，
Refer 谷歌 OAuth2 文档 https://developers.google.com/identity/protocols/OAuth2#expiration
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
