offline_access弃用和场景3和4

Question

每次我读https://developers.facebook.com/roadmap/offline-access-removal/的时候，我都比以前更加困惑。我想对场景3和4(服务器端应用程序和客户端应用程序)下的一些项目进行一些澄清。

对于服务器端应用程序，它声明“如果调用是在该用户仍然有一个有效的60天access_token的情况下进行的，则第二个调用返回的access_token可能是相同的，或者可能已经更改，但无论是哪种情况，到期时间都将是新的60天。”

• 这里所指的“电话”是什么？
• 是否与初始OAuth流期间发生的访问令牌的授权代码交换相同？
• 还是客户端部分中描述的端点调用将令牌更新为60天？
• 如果是前者，那么在尝试更新令牌时授权代码从何而来？
• 是来自原始回调的相同授权代码，还是必须再次遍历授权流？

简而言之，服务器端的应用程序能否不断更新60天令牌的生命，如果是的话，那是如何做到的呢？

关于客户端的使用，文档指出客户端必须使端点调用传入应用程序的客户机ID和客户端机密。

• 我对“客户端”的解释可能是错误的，但我考虑的是一个在web浏览器中运行的基于JavaScript的客户端。
• 如果这就是Facebook在这里想要的，那么JavaScript代码真的应该知道客户端的秘密吗？(如果把它发送给客户，那就不是什么秘密了。)

即使如此，它也表明，60天代币不能延长寿命，必须首先获得新的2小时令牌，并使用它来获得60天的令牌。这是文档的客户端部分，但是这个规则也适用于服务器端60天的令牌吗？如果不是，那么我再问一遍:如何更新服务器端60天令牌的生命？

最后，我脑海中一直萦绕着的问题是:为什么Facebook采用这种策略而不采用OAuth 2规范( Facebook正在帮助定义的规范)中定义的刷新令牌？

编辑:重新阅读文档后的进一步思考/问题：

在一开始，它说“一个长寿命的到期时间，可以延长每次用户恢复你的应用程序”。我最初的假设是，更新它的方法是调用文档后面的端点。但是，除了在“客户端”标题下描述端点这一事实之外，它还声明“请注意，端点只能用于扩展短暂的用户access_tokens，如果您传递一个具有较长过期时间的access_token，端点将简单地将相同的access_token传递给您，而不会更改或延长过期时间。”(“长时间感到不安”的错误来自FB自己的文件。)

好的，如果不能使用这个端点来更新过期时间(我自己尝试用这个端点来更新一个长寿命令牌，就证明了这一点)，那么每次他们访问我的应用程序时，我如何才能对一个长寿令牌更新过期时间呢？

难道没有人知道这是怎么回事吗？

Answer 1

在阅读了Facebook的文档(比如第五次)之后，在这个问题/答案的帮助下，这是我的结论。

这里所指的“电话”是什么？

它引用OAuth调用来获取访问令牌。

是否与初始OAuth流期间发生的访问令牌的授权代码交换相同？

是的，我相信就是那股水流。

还是客户端部分中描述的端点调用将令牌更新为60天？

不，该端点仅对短暂的访问令牌有效。

是来自原始回调的相同授权代码，还是必须再次遍历授权流？

你必须再次检查授权流程。

每次他们访问我的应用程序时，我怎样才能更新一个长寿令牌的过期时间呢？

不能使用客户端端点更新长寿命访问令牌。用户将不得不重新授权该应用程序，以获得一个新的。根据Facebook的文件：

如果调用(OAuth授权调用)是在该用户的有效长寿命用户access_token仍然存在的情况下进行的，则该第二次调用返回的用户access_token可能是相同的，或者可能已经更改，但在任何一种情况下，过期时间都将设置为长过期时间。

一旦应用程序被重新授权，您将得到一个新的过期时间。Facebook可能会返回一个新的长寿访问令牌，所以您应该抓住它，并将这些信息替换为您已经拥有的信息。

结论:似乎在没有用户干预的情况下，更新一个长期访问令牌是不可能的。要获得新的过期时间/访问令牌，他们必须重新授权您的应用程序。我的建议是，应该建议用户在到期前几天重新授权。此外，这个Facebook如何-to可以方便地检查过期的访问令牌。