Oauth 脱机访问不推荐和场景3和4

每次我阅读，我都比以前更加困惑。我想对场景3和场景4（服务器端应用和客户端应用）下的一些项目进行澄清

对于服务器端应用程序，它声明“如果呼叫是在该用户仍有有效的60天访问\u令牌的情况下进行的，则第二次呼叫返回的访问\u令牌可能相同或已更改，但在任何一种情况下，过期时间都将是新的60天。”

• 这里提到的“电话”是什么
• 是不是在初始OAuth流期间为访问令牌交换了相同的授权码
• 还是客户端部分中描述的端点调用将令牌更新为60天
• 如果是前者，那么在尝试续订令牌时授权代码来自何处
• 它是否与原始回调中的授权代码相同，还是我必须再次通过授权流

简言之，服务器端应用程序能否持续刷新60天代币的生命？如果是，如何

关于客户端使用，文档指出客户端必须使端点调用传入（除其他外）应用程序的客户端ID和客户端机密

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

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

最后，一个在我脑海中燃烧了一段时间的问题：为什么Facebook采用了这种策略，而没有采用OAuth 2规范（Facebook帮助定义的规范）中定义的刷新令牌

编辑：再次阅读文档后的进一步想法/问题：

开始时，它说“一个长期有效的到期时间，用户每次修改你的应用程序时都可以续期”。我最初的假设是，更新它的方法是在文档的后面调用端点。但是，除了端点在“客户端”标题下描述之外，它还声明“请注意，端点只能用于扩展短期用户访问令牌。如果您传递了过期时间较长的访问令牌，则端点只需将相同的访问令牌传递回您，而不会更改或延长过期时间。”（键入“long lieved”的内容来自FB自己的文档。）

好的，那么如果该端点不能用于延长到期时间（我自己尝试使用该端点延长长寿命令牌的尝试证明了这一点），那么我如何在他们每次访问我的应用程序时延长长寿命令牌的到期时间

---

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

在阅读了Facebook的文档（比如第五次）之后，在这篇文章的帮助下，我得出了一些结论

这里提到的“电话”是什么

它引用OAuth调用以获取访问令牌

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

是的，我相信就是这样

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

否，该端点仅对短期访问令牌有效

是与原始回调中的授权码相同，还是相同 必须再次通过授权流程吗

您必须再次通过授权流程

如何每次续订长寿命令牌的过期时间 他们访问我的应用程序

无法使用客户端终结点续订长寿命访问令牌。用户必须重新授权应用程序才能获得新令牌。 根据Facebook文档：

如果调用（OAuth授权调用）是在仍然存在有效的长期用户时进行的 访问该用户的\u令牌，从该用户返回的用户访问\u令牌 第二次呼叫可能相同，也可能已更改，但在任何一种情况下 到期时间将设置为较长的到期时间

一旦应用程序被重新授权，你将获得一个新的过期时间。Facebook可能会返回一个新的长期访问令牌，因此你应该获取它，并将该信息替换为你已经拥有的信息

结论: 在没有用户干预的情况下，似乎无法续订长期访问令牌。要获得新的过期时间/访问令牌，他们必须重新授权你的应用。我的拙劣建议是，应该建议用户在过期日期前几天重新授权。

---

此外，这对于检查过期的访问令牌也很方便。

我确实有你同样的疑问。我很高兴我发现了这个问题，但当我发现没有人回答这个问题时，我所有的快乐都破灭了。我不知道是我还是Facebook写的文档真的很糟糕。