我刚刚将我们的 Box 代码升级到 OAuth2。
我们已经实现了允许用户在我们的网络服务器和他们的 Box（以及 SkyDrive、Dropbox、Google Drive）帐户之间传输文件的代码。用户的访问和刷新令牌存储在我们的数据库服务器中。
根据http://developers.box.com/oauth/，它说 每个刷新令牌的有效期为 60 天
SkyDrive 和 Drive 都使用 OAuth2，并且没有刷新令牌到期。是否可以有永不过期的刷新令牌？
某些应用程序可能不需要刷新令牌，那么您是否会考虑引入新的 OAuth2 范围，例如
据我了解，Box OAuth2 实现使用可选的刷新令牌轮换方案，每次发出访问令牌时，也会发出一个新的刷新令牌。请参阅oauth 规范文档的第 10.4 节。这是一项可选功能，Google 和 Microsoft 不使用该功能，因为它们为 OAuth2 实现发布永久刷新令牌（或者至少刷新具有足够长生命周期的令牌，所以它不是真正的问题）。
在我看来，这是 Box 的一个非常不幸的选择。
您在应用程序中要做的是，每次请求新的访问令牌时，您还必须保存返回的新刷新令牌，以便下次请求访问令牌时使用新的刷新令牌。这样一来，您最终会得到一个过期的刷新令牌的唯一情况是，如果用户 60 天没有使用他们的 Box 登录。只要他们积极使用该应用程序，您就会获得新的刷新令牌，并且 60 天的生命周期不是问题。到目前为止一切都很好，但这并不总是如此，现在是吗？
我的问题是，您必须在每个请求上保存刷新令牌，但是如果由于某种原因失败了怎么办：网络中断，电池电量不足，磁盘写入异常，您的应用程序被关闭操作系统....那么您将不得不要求用户再次登录，而用户将责怪应用程序开发人员。
如果您有足够的用户使用您的应用程序，这将会发生。随着时间的推移，可能只有 2-5%，但在我看来这仍然是一个大问题。
至少如果刷新令牌是（半）永久的，您可以重试身份验证过程，直到它完成。然后你知道你已经保存了令牌，当上述情况发生时，你可以继续使用它，也可以重试，但轮换方案并非如此。
我已经在考虑为遇到此问题的用户制作标准支持电子邮件，并链接到此问题。
感谢您的意见，Box 已根据此反馈更改了我们处理刷新令牌的方式，以及与我们的一些合作伙伴开发人员和客户的一些详细讨论。
盒子从 14 天移到 60 天。这本身应该会减少超出大多数应用程序开发人员对其应用程序所需的超时用户数。
我们还可能更重要的是，当网络错误发生时，我们不会在发布新令牌后立即使刷新令牌无效。如果由于某种原因您没有获得新的刷新令牌，只需回调以使用旧的刷新令牌获取新令牌。您可以根据需要多次执行此操作，直到获得新的访问令牌和刷新令牌。
一旦您使用新的访问令牌成功调用，我们就知道您已经获得了新的对，并且我们使旧的刷新令牌无效。这也有助于多服务器环境更好地工作，因为获取新 RT 的同时请求将从集群中的多个服务器工作。