0

我了解 TweetDeck 可以帮助用户代表她访问 Twitter 和 Facebook。

在OAuth2中，这意味着 TweetDeck 是第 3 方应用程序，Twitter 和 Facebook 是资源服务器，而用户是资源所有者。

我的问题不是关于 TweetDeck 代表资源所有者访问某些资源服务器。

我的问题是 TweetDeck 如何处理其自己的桌面应用程序/移动应用程序/webapp 的身份验证，因为在所有 3 种类型中，用户仍然需要使用她自己的 TweetDeck用户名/密码登录？

对于 webapp，这很简单。TweetDeck 可以使用良好的服务器会话和浏览器 cookie 来维护应用程序/身份验证状态以及通过 HTTPS 的简单登录表单。

我的主要问题是桌面应用程序/移动应用程序呢？

TweetDeck 是否也使用 OAuth2 进行自己的身份验证？如果没有，它有什么用？

如果是这样，是资源所有者密码凭据授予吗？如果不是，那么哪种类型的 OAuth 授权？

如果是这样，他们如何避免受到暴力攻击的危害？由于它在文档中说明，因此端点需要防止暴力攻击。

4

1 回答 1

0

它使用带有自定义会话实现的HTTP 基本身份验证。它不是 OAuth2 的Resource Owner's Password Credentials Grant的实现，因为我没有在下面的测试运行中指定一些 必需的参数（例如grant_type）并且服务器没有抱怨。

这是我使用 cUrl 进行的本地运行：

    ∴  curl -v https://opyate%40gmail.com:mysupersecretpassword@api.tweetdeck.com/login\?session\=true
    * About to connect() to api.tweetdeck.com port 443 (#0)
    *   Trying 199.59.149.231...
    * connected
    * Connected to api.tweetdeck.com (199.59.149.231) port 443 (#0)
    * successfully set certificate verify locations:
    *   CAfile: /opt/local/share/curl/curl-ca-bundle.crt
      CApath: none
    * SSLv3, TLS handshake, Client hello (1):
    * SSLv3, TLS handshake, Server hello (2):
    * SSLv3, TLS handshake, CERT (11):
    * SSLv3, TLS handshake, Server finished (14):
    * SSLv3, TLS handshake, Client key exchange (16):
    * SSLv3, TLS change cipher, Client hello (1):
    * SSLv3, TLS handshake, Finished (20):
    * SSLv3, TLS change cipher, Client hello (1):
    * SSLv3, TLS handshake, Finished (20):
    * SSL connection using RC4-SHA
    * Server certificate:
    *    subject: C=US; ST=CA; L=San Francisco; O=Twitter, Inc.; OU=Twitter Security; CN=tdweb.twitter.com
    *    start date: 2012-02-23 00:00:00 GMT
    *    expire date: 2015-02-27 12:00:00 GMT
    *    subjectAltName: api.tweetdeck.com matched
    *    issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert High Assurance CA-3
    *    SSL certificate verify ok.
    * Server auth using Basic with user 'opyate@gmail.com'
    > GET /login?session=true HTTP/1.1
    > Authorization: Basic 1337YfRl1337YWl1337vbTpzdXJmYTMyMA==
    > User-Agent: curl/7.25.0 (x86_64-apple-darwin10.8.0) libcurl/7.25.0 OpenSSL/1.0.1c zlib/1.2.7 libidn/1.22
    > Host: api.tweetdeck.com
    > Accept: */*
    > 
    < HTTP/1.1 200 OK
    < Transfer-Encoding: chunked
    < Date: Tue, 12 Jun 2012 12:59:47 GMT
    < Expires: Fri, 21 Mar 1975 09:30:00 GMT
    < Content-Type: text/html
    < Cache-Control: no-cache
    < Cache-Control: no-store
    < Cache-Control: must-revalidate
    < Cache-Control: pre-check=0
    < Cache-Control: post-check=0
    < Server: tfe
    < 
    * Connection #0 to host api.tweetdeck.com left intact
    {"mail_list": "False", "session": "Ta1337Qb1wu1337Ra29b1337-13371337Vbf93y91337", "updated_time": "2011-12-08T12:31:00"}* Closing connection #0
    * SSLv3, TLS alert, Client hello (1):

顺便说一句，我从 Chrome 开发人员工具会话中获得了该登录 URL：

在此处输入图像描述

更新

我问过 TweetDeck 自己，但在撰写本文时，他们还没有回复。

于 2012-06-12T13:02:04.433 回答