Facebook将在 2012 年 5 月弃用该offline_access许可，并且文档没有为我们提供有关如何处理它的足够信息。
我们有一个 iOS 应用程序和相应的服务，为其提供支持并与 Facebook 深度集成，以在应用程序内利用用户的朋友列表（因此，如果您的 FB 朋友也在使用该应用程序，您可以更轻松地建立联系）。这就像所有社交应用程序的工作方式一样，所以这里没什么特别的。
客户
我们的应用程序使用Facebook iOS SDK来允许用户登录，这是我们目前要求的offline_access。令牌保留在我们的 iOS 应用程序中，但也会发送到保存它的服务器。客户端代表用户向用户的新闻源发布更新（我们也请求publish_stream许可）。
服务器
我们的服务器会定期检查用户的 FB 好友是否正在使用我们的应用程序。下次用户登录时，我们会以某种方式公开内容和关系以宣传该用户的朋友。服务器还代表用户定期连接到图 API 并获取用户的当前好友列表。这样我们就可以解释用户关系的变化，并将它们反映在我们的应用程序中。当用户当前未使用该应用程序时，我们会执行此操作，以便他们在下次使用该应用程序时获得最佳体验。为了实现这一点，我们的 iOS 应用程序将访问令牌发送到它使用的服务器以及我们请求的原因offline_access。
注意：如果用户明确退出我们的应用程序，我们会从客户端和服务器中删除访问令牌。
问题
既然不再有我们可以使用的永久访问令牌，我正在尝试找出在利用 facebook 处理和扩展访问令牌的新预期方式的同时仍然启用我们的场景的最佳实践。不幸的是，文档并不完全有帮助。
问题
A.当您通过最新的 Facebook iOS SDK 进行身份验证时，您获得的访问令牌的默认生命周期是多少？这份文件说，一个扩展的令牌请求会给你一个持续 60 天的令牌。另一个文档讨论了第一个访问令牌请求并提到了不同的有效性，但不清楚，它是否讨论了具体的有效性时间：
（重点是我的）
当您从 Facebook 获得访问令牌时，它将立即生效，并可在 Facebook 定义的一段时间内用于对 API 的请求。这段时间过去后，访问令牌被视为已过期，用户将需要再次进行身份验证，以便您的应用程序获得新的访问令牌。给定访问令牌的有效期取决于它的生成方式。
还有一些事件可能导致访问令牌在其预期到期时间之前变得无效。此类事件包括用户更改密码、应用程序刷新其 App Secret。处理不同的访问令牌到期时间，以及处理访问令牌在其预期到期时间之前失效的情况对于构建强大的社交体验至关重要。
B.对于客户来说，既然访问令牌不一定是长期存在的，那么我们的正确方法是：
让我们通过 FB 使用登录，然后检测访问令牌何时过期。如果是，那么调用FB iOS SDK重新认证/重新授权？（这应该只会触发用户跳出到 FB iOS 应用程序，并且在大多数情况下会立即使用新的访问令牌返回我们的应用程序）。
C.根据我发现的这篇博文，您只能扩展一次访问令牌：
我可以将我的 60 天访问令牌换成新的 60 天访问令牌吗？
不，对不起，你不能。您只能将有效（即当前）用户访问令牌交换为扩展令牌。您不能扩展已扩展的访问令牌。
在客户端，我可以通过提示重新认证/重新授权来处理这个问题，正如我在问题 B 中提到的那样。但是，这在我们的服务器上不起作用。我们当然可以让服务器将它更新一次到 60 天，但是在第 61 天会发生什么？服务器只是停止能够同步朋友的列表？
D.每次应用程序启动或从睡眠状态恢复时检查 FB 访问令牌的有效性似乎是有意义的。我们的 iOS 应用程序检查这一点的最佳方法是什么？是否有推荐的端点来调用以验证令牌？我们是否应该调用https://graph.facebook.com/me传递访问令牌并检查响应？
注意：我们当然可以记录expires我们获得初始扩展令牌的时间，但这并不可靠，因为用户可以随时撤销我们应用程序的权限，这使得expires时间成为不可靠的有效性数据点