【发布时间】：2013-03-11 23:08:06
【问题描述】：
每个刷新令牌的有效期为 14 天。为什么刷新令牌会过期？
【问题讨论】：
-
在应用被用户撤销之前，刷新令牌不会过期。 stackoverflow.com/questions/8953983/…
【发布时间】：2013-03-11 23:08:06
【问题描述】：
14 天基于实施 OAuth2 的最佳实践。请参阅Why do access tokens expire?，以获得有关 OAuth2 刷新令牌为何过期的非常全面的答案。
我们很想知道哪个大于 14 的数字适合您的应用程序。我们根据初步反馈、应用程序开发人员的调查以及查看用户的应用程序登录情况选择了 14 天。绝大多数用户使用应用程序登录的频率高于每 14 天一次。
您能解释一下您的用例吗？什么是理想的非无限刷新间隔，可以让您在安全性和便利性之间取得平衡
【讨论】：
-
我不同意你关于这个通常刷新令牌持续很长时间而不是有限的天数，我需要一次又一次地让用户参与进来，这是不好的实现看看这篇文章stackoverflow.com/questions/8953983/…
-
如果您的用户不是每 14 天使用一次您的应用程序，他们是否应该重新进行身份验证？大多数商业应用程序被人们每周至少使用一次，如果不是更频繁的话。要求用户在长假回来后重新认证似乎是完全合理的。您能解释一下为什么您的用户没有在常规练习中至少每 14 天使用一次您的应用吗？
-
@PlatformBoxer 并非所有应用程序都是面向用户的，或者有一些用户希望在通过一次身份验证后继续工作的后台进程。通常这是通过让应用程序请求“离线访问”来完成的（参见 facebook、twitter 和其他所有内容），并且如果获得批准，开发人员能够请求永久令牌。
-
我知道并非所有应用程序都是面向用户的。我也写过 cron-tab 作业。然而，我们在这里谈论的是一个企业潜在的皇冠宝石。许多其他商业产品只提供“长期存在的”OAuth2 令牌。见谷歌。奇怪的是他们没有定义“长”。您是否正在做超过 14 天的 cron 选项卡？几天？每月？季刊？每年？通常多久需要更改一次加密密钥的长度？我们正在讨论什么更长的时间段是合理的。你有提议吗？
-
我们刚刚将 refresh_tokens 更新为 60 天，而不是 14 天，这基于来自应用程序的一些数据，这些应用程序的用户仅每月登录一次。