Facebook Graph API：有应用访问令牌，需要用户访问令牌而无需交互

Posted 2023-04-13

【中文标题】Facebook Graph API：有应用访问令牌，需要用户访问令牌而无需交互

【英文标题】：Facebook Graph API: Have app access token, need user access token without interaction

【发布时间】：2012-09-05 23:22:54

【问题描述】：

我们有一个音频博客网站，可以将其配置为在用户创建新博客条目时发布指向用户 Facebook 时间线的链接。

为此，我们让用户在设置指向其 Facebook 帐户的链接时授权我们的应用程序。我们获得了 publish_stream、offline_access 和 ma​​nage_pages 权限（稍后会详细介绍）。

所有代码都使用 C#，但原则适用于任何语言，因为它是我们关注的 Facebook API 的工作原理。我们正在使用 OAuth 2 和 Graph API 来实现这一切。

因此，我们使用我们的应用 ID 和 secret 获得一个 应用访问令牌，并使用该令牌发布到用户的时间线，这工作正常（因为他们已经授权我们的应用程序这样做）。我们还可以查询 Graph API 并获取他们的赞、朋友和其他各种数据。

问题来了：

我们的一些用户希望将更新发布到他们自己的时间线以及他们管理的页面的时间线。理论上这很简单：您使用此 url 查询用户管理的页面的 API：https://graph.facebook.com/userid/accounts?access_token=token

据说从该调用返回的 JSON 包含页面 ID 和这些页面的页面访问令牌。然后，您使用页面访问令牌发布到页面的时间线。

但是，当我们尝试使用 应用访问令牌 调用此 URL 时，我们会收到 OAuthException 102“请求此资源需要用户访问令牌”。

请注意，这与 OAuthException 104 “请求此资源需要访问令牌”（如果您忽略传递访问令牌，您会得到）以及 OAuthException 190 “无效的 OAuth 访问令牌签名”（如果访问令牌不是有效的，您会得到）。

所以我们的访问令牌是有效的，但对这个特定的 url 无效。因此，对于这个特定的提要，我们似乎需要一个 用户访问令牌 而不是 应用访问令牌（我早就不在乎为什么会这样了，它似乎只是就这样吧）。

关于这个主题的所有 Facebook 文档（我现在一定已经阅读了所有文档）指向一个地方：http://developers.facebook.com/docs/authentication/server-side/，也就是“服务器端身份验证流程”页面。本页面描述了如何通过将用户重定向到身份验证对话框并请求相关权限来获取难以捉摸的用户访问令牌但是我们需要在没有用户交互的情况下实现这一点，并且用户已经为我们的应用程序提供了所有权限我们需要。所有这些自动发布都发生在音频后处理的服务器端，因此我们无法在此阶段与用户进行交互。

我不明白。为什么我们可以使用应用访问令牌从用户那里获取我们想要的几乎任何数据（好吧，无论他们给了我们获取什么权限）但是我们需要不同的 /accounts 数据（用户) 访问令牌？

谁能阐明我们如何获得用户访问令牌，这将允许我们在不与用户进行任何进一步交互的情况下为我们的用户获取 /accounts 数据？

【问题讨论】：

我也有同样的问题，你是怎么解决的？

【参考方案1】：

所以我们的访问令牌是有效的，但对这个特定的 url 无效。因此，对于这个特定的提要，我们似乎需要一个用户访问令牌，而不是一个应用访问令牌

由于每种访问令牌的权限，在这种特殊情况下，您确实需要一个有效的用户访问令牌。 Read all about access tokens and types。就是这样。

本页描述了如何通过将用户重定向到身份验证对话框并请求相关权限来获取难以捉摸的用户访问令牌但是我们需要在没有用户交互的情况下实现这一点，并且用户已经给了我们的应用程序我们需要的所有权限。

如果您的用户已经授予他/她的权限，那么您为什么还要苦苦挣扎？我建议您保留用户访问令牌。来自this endpoint：

https://www.facebook.com/dialog/oauth?client_id=..&redirect_uri=..&state=..&scope=..&response_type=..&display=.."

您检索代码，如下所示：

YOUR_REDIRECT_URI?code=OAUTH_CODE_GENERATED_BY_FACEBOOK&state=YOUR_STATE_VALUE

使用此代码生成您的用户访问令牌，如 here 所述：

https://graph.facebook.com/oauth/access_token?client_id=..&redirect_uri=..&client_secret=..&code=..

这将导致如下响应：

access_token=USER_ACCESS_TOKEN&expires=NUMBER_OF_SECONDS_UNTIL_TOKEN_EXPIRES

就是这样，您的用户访问令牌。坚持下去。如您所见，它在响应中指示的值之后过期。如果您使用新的 API，它应该表示 60 天（这让我回到了这一点：不推荐使用 offline_access 并导致短期 - 有效期为 2 小时 - 令牌），link。每当您的用户登录到您的应用并使用 Facebook 集成时，令牌都会再次刷新到 60 天。这意味着，如果您的用户不应该登录您的应用程序并使用它 60 天，它将过期。

您可以检查用户访问令牌是否过期：

https://graph.facebook.com/debug_token?input_token=INPUT_TOKEN&access_token=ACCESS_TOKEN

如果是这样：使用您的应用访问令牌更新用户访问令牌，这是有据可查的right over here。但我引用了这部分：

服务器端登录 在这种情况下，要获得新的 [user] 访问令牌，您必须再次让用户通过完整的服务器端登录流程。但是，假设用户没有取消对您的应用的授权，当您将用户重定向到 OAuth Dialog 时，他们不会被提示重新授权您的应用，而是会立即重定向到 redirect_uri。这意味着重新认证过程对用户来说是相当透明的。

底线：没有永远有效的用户访问令牌，但应用程序访问令牌是。保留您的用户访问令牌并在使用它执行 API 调用之前检查它是否仍然有效。普通用户应在 60 天内使用您的应用，而不仅仅是为了好玩而取消对您的应用的授权。因此，用户应该重新授权的用例相当少见，但是，您需要期待它。

【讨论】：

非常感谢，我们现在有一个可行的解决方案！我们的问题是直到最近我们才需要用户令牌，因为应用令牌允许我们做我们需要的事情。我们现在正在获取用户令牌并将其持久化，然后在何时使用它来获取页面令牌。