【问题标题】:How to verify Facebook access token?如何验证 Facebook 访问令牌?
【发布时间】:2012-01-26 04:51:33
【问题描述】:

服务器只需要做一件事;只需检查任何访问令牌的有效性。

客户端向服务器发送FB.getLoginStatus获取的用户ID和访问令牌。正如我所料,会有任何 URL 检查访问令牌的有效性,例如 http://xxx.facebook.com/access_token?=xxxxxxxxxxxxxxxxxxxxxxxxxxxx

返回它是否可用,或者是否有任何 API(服务器端)?

【问题讨论】:

标签: facebook


【解决方案1】:

如果遇到错误,您可以简单地请求https://graph.facebook.com/me?access_token=xxxxxxxxxxxxxxxxx,令牌无效。如果你得到一个带有 id 属性的 JSON 对象,那么它是有效的。

不幸的是,这只会告诉您您的令牌是否有效,而不是它是否来自您的应用程序。

【讨论】:

【解决方案2】:

官方支持的方法是:

GET graph.facebook.com/debug_token?
     input_token={token-to-inspect}
     &access_token={app-token-or-admin-token}

更多信息请参见the check token docs

一个示例响应是:

{
    "data": {
        "app_id": 138483919580948, 
        "application": "Social Cafe", 
        "expires_at": 1352419328, 
        "is_valid": true, 
        "issued_at": 1347235328, 
        "metadata": {
            "sso": "iphone-safari"
        }, 
        "scopes": [
            "email", 
            "publish_actions"
        ], 
        "user_id": 1207059
    }
}

【讨论】:

  • 我认为说 facebook 更有可能引入重大更改是一种误导。他们没有在任何地方声明,他们的官方文档明确表示这是验证访问令牌的方法
  • @rynop,好吧,API 端点的名称是“debug_token”,它在 Facebook API 文档中标记为 Getting Info about Tokens and Debugging 的部分中进行了描述。文档的这一部分由 HTML 锚#debug 引用,并声明 API 是其调试工具的后端。对我来说似乎很清楚,但是从技术上讲,您是对的,没有任何地方清楚直接地说明该功能不适用于生产用途... :-)
  • 这里的主要问题是,如果数据来自客户端,则使用 me?access_token 方法是完全错误的;因为任何网站都可以获取令牌,然后通过访问您的 api 使用它们对您的网站进行身份验证。
  • OP 想要检查与令牌关联的用户 ID。 /me 端点返回用户 ID,但前提是访问令牌有效(因为毕竟,令牌用于确定要返回的 哪个“我”)。所以,抓住 /me 并比较用户 ID。必须记住,每个应用程序都有自己的特殊范围的用户 ID,因此您无法将来自不同来源的 ID 与您使用自己的应用程序令牌获得的 /me 进行比较。
  • 过去的文档可能会引用它来进行调试。但目前它表明这正是用例。
【解决方案3】:

Access Token 交换为Mobile Number and Country Code(服务器端或客户端)

您可以通过access_token 和此API https://graph.accountkit.com/v1.1/me/?access_token=xxxxxxxxxxxx 获得mobile number。也许,一旦您拥有了mobile numberid,您就可以使用它来验证 使用您的server & database 的用户。

xxxxxxxxxx 上面是Access Token

示例响应:

{
   "id": "61940819992708",
   "phone": {
      "number": "+91XX82923912",
      "country_prefix": "91",
      "national_number": "XX82923912"
   }
}


Auth Code 交换为Access Token(服务器端)

如果你有一个Auth Code,你可以先用这个Access Token 得到API - https://graph.accountkit.com/v1.1/access_token?grant_type=authorization_code&code=xxxxxxxxxx&access_token=AA|yyyyyyyyyy|zzzzzzzzzz

上面的xxxxxxxxxxyyyyyyyyyyzzzzzzzzzz分别是Auth CodeApp IDApp Secret

示例响应

{
   "id": "619XX819992708",
   "access_token": "EMAWdcsi711meGS2qQpNk4XBTwUBIDtqYAKoZBbBZAEZCZAXyWVbqvKUyKgDZBniZBFwKVyoVGHXnquCcikBqc9ROF2qAxLRrqBYAvXknwND3dhHU0iLZCRwBNHNlyQZD",
   "token_refresh_interval_sec": XX92000
}

注意 - 这是server-side 的首选,因为API 需要APP Secret,而shared 并不意味着security reasons

祝你好运。

【讨论】:

    【解决方案4】:

    只是想让你知道,直到今天我首先获得了一个应用访问令牌(通过对 Facebook 的 GET 请求),然后使用收到的令牌作为app-token-or-admin-token in:

    GET graph.facebook.com/debug_token?
        input_token={token-to-inspect}
        &access_token={app-token-or-admin-token}
    

    但是,我刚刚意识到了一种更好的方法(另外一个好处是需要更少的 GET 请求):

    GET graph.facebook.com/debug_token?
        input_token={token-to-inspect}
        &access_token={app_id}|{app_secret}
    

    如 Facebook 的访问令牌文档中所述here

    【讨论】:

    • 谢谢。其他人的注意事项:文字“|”必须包含字符(不表示“或”),如答案中链接到的页面所示:developers.facebook.com/docs/facebook-login/…
    • 这不是不安全的吗?通过 URL 查询参数发送 app-secret 会将其暴露给服务器和 Facebook 之间“中间”的任何人,并且 HTTPS 无济于事,因为 URL 未加密。任何人都可以使用 debug_token 格式的 URL“监听”(嗅探)请求并窃取 Facebook 应用程序机密。
    • @Xeing 谢谢,我明白我的印象是错误的 :) 似乎只是 URL 的主机部分没有加密。
    • 添加“|”有了应用程序的秘密,我终于走了。否则此 API 不起作用。
    【解决方案5】:

    可以从此网址找到应用令牌。

    https://developers.facebook.com/tools/accesstoken

    【讨论】:

      【解决方案6】:

      简单请求(HTTP GET):

      https://graph.facebook.com/USER_ID/access_token=xxxxxxxxxxxxxxxxx
      

      就是这样。

      【讨论】:

        【解决方案7】:

        我从 facebook 开发者页面找到了这个官方工具,这个页面将让您关注与访问令牌相关的信息 - 应用 ID、类型、应用范围、用户上次安装此应用的方式、已发布、过期、数据访问过期、有效、起源,范围。 只需要访问令牌。

        https://developers.facebook.com/tools/debug/accesstoken/

        【讨论】:

          猜你喜欢
          • 2015-02-25
          • 1970-01-01
          • 1970-01-01
          • 2016-09-04
          • 2022-10-15
          • 2015-07-16
          • 2012-09-18
          • 2013-01-10
          • 2012-01-19
          相关资源
          最近更新 更多