What authentication mechanism does TweetDeck use for their desktop app/mobile app/web app?

Question

I understand that TweetDeck can help a user to access Twitter and Facebook on her behalf.

In OAuth2, that means TweetDeck is the 3rd Party Application, Twitter and Facebook are the Resource Server while the user is the Resource Owner.

My question is NOT about TweetDeck accessing some Resource Server on behalf of a Resource Owner.

My question is how does TweetDeck handle authentication for its own desktop app/mobile app/webapp because in all 3 types, a user still needs to login using her own TweetDeck username/password?

For webapp, it is straightforward enough. TweetDeck could be using good ol' server sessions and browser cookies to maintain application/authentication state and a simple login form over HTTPS.

My main question is What about desktop app/mobile app?

Does TweetDeck also use OAuth2 for its own authentication? if not, what does it use?

If so, is it Resource Owner Password Credentials Grant? if not, then which type of OAuth grant?

If so, how do they avoid being compromised by brute force attacks? since it is stated in the docs, the endpoint for this needs to protect against brute force attacks.

Answer 1

It uses HTTP Basic Authentication with a custom session implementation. It's not an implementation of OAuth2's Resource Owner's Password Credentials Grant, because I didn't specify some of the required parameters (e.g. grant_type) in my test run below and the server didn't complain.

Here's a local run I did using 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):

BTW, I got that login URL from a Chrome Developer Tools session:

---

UPDATE

I asked TweetDeck themselves, but at the time of writing they haven't replied yet.