TweetDeck使用哪种身份验证机制用于桌面应用/移动应用/网络应用？

Question

据我所知，TweetDeck可以帮助用户代表她访问Twitter和Facebook。

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

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

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

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

我的主要问题是桌面应用/移动应用怎么样？

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

如果是，是Resource Owner Password Credentials Grant吗？如果没有，那么哪种OAuth授权？

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

Answer 1

它使用HTTP Basic Authentication和自定义会话实现。这不是OAuth2的资源所有者密码凭证授权的实现，因为我在下面的测试运行中没有指定一些required parameters（例如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开发者工具会话中获得了该登录网址：

---

<强>更新

I asked TweetDeck themselves，但在撰写本文时，他们还没有回复。