TweetDeck用于桌面应用程序/移动应用程序/ Web应用程序的认证机制是什么？

我明白TweetDeck可以帮助用户代表她访问Twitter和Facebook。TweetDeck用于桌面应用程序/移动应用程序/ Web应用程序的认证机制是什么？

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

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

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

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

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

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

如果是这样，是不是Resource Owner Password Credentials Grant？如果不是，那么哪种类型的OAuth授予？

如果是这样，他们如何避免受到暴力攻击的危害？因为它是在文档中陈述的，所以这个端点需要防止暴力攻击。

来源

2012-06-09 Kim Stacks

用户不是客户端，因为客户端是第三方应用程序。用户是资源所有者。 –

固定。谢谢@ArtemOboturov –

它使用HTTP Basic Authentication自定义会话实现。这不是OAuth2的资源所有者的密码凭证授权的实现，因为我在下面的测试运行中未指定某些required parameters（例如grant_type），并且服务器没有投诉。

这是我没有使用curl这样的本地运行：

∴ curl -v https://opyate%40gmail.com:[email protected]/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 '[email protected]' 
    > 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):

BTW，我接到了一个Chrome开发者工具会话登录网址：

enter image description here

UPDATE

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

来源

2012-06-12 13:02:04 opyate

所以我正确吗，即使对于桌面和移动应用程序，Tweetdeck也能做到这一点？ –

对不起，我认为大多数人看到SPA和桌面应用程序是一样的。我下载/安装了Adobe AIR Tweetdeck客户端，我通过Wireshark看到的第一件事情是对api.tweetdeck.com的SSL CONNECT调用，所以大概是的。 – opyate

我试图使用Charles，但由于SSL而看不到任何参数。它们是否包含代码，client_id，client_secret，access_tokens之类的参数？如果他们不这样做，那么我猜他们不会使用OAuth登录 –

TweetDeck用于桌面应用程序/移动应用程序/ Web应用程序的认证机制是什么？

回答

相关问题