bos*_*cko 5 storage authorization access-token oauth-2.0 jwt
在 OAuth 2 的背景下，如何处理refresh_token过期或缺失问题？
我使用 JSON Web Tokens (JWT) 作为access_tokens，其生命周期较短（20 分钟后过期）。据我了解，这意味着我不必存储access_token，而只需验证它（并使用内部的可信信息，例如范围）。
不过，我想知道如何实现refresh_tokens. 在我的研究中，我发现谷歌和其他公司的refresh_token协议永远有效，除非它们因各种原因被撤销。我认为这意味着系统必须存储所有发出的刷新令牌，这样它们就可以被标记为已撤销。
当涉及到代币的存储时，这是一个问题吗？似乎您有一组潜在的无限令牌需要永久存储和访问。
我错过了什么吗？是否有实施刷新令牌的最佳实践？它们应该是（还是不是）JWT？即使使用 JWT，是否也应该存储 access_token？如果是这样，是否有任何理由让它们超过有效期？JWT 秘密会随着时间的推移而变化吗？
这是一个很好的问题，并且刷新令牌通常不会过期，因此应用程序可以生成新的访问令牌，而无需要求用户定期重新进行身份验证，
但应用程序需要对单个客户端允许的活动刷新令牌数量实施限制，例如：
每个 OAuth 客户端最多只能有 20 个活动的刷新令牌，如果达到该限制，则必须撤销最旧的令牌，并应在不拒绝请求的情况下授予新的令牌。
而且，如果刷新令牌在一段时间内（例如 6 个月）没有被消耗，那么该令牌也需要被撤销。
通过这种方式，你可以对refresh_token的消耗进行限制，这里有一个问题，谷歌也是这样做的，
| 归档时间： |
|
| 查看次数： |
5602 次 |
| 最近记录： |