0

TweetDeck が、ユーザーが代わりに Twitter や Facebook にアクセスするのに役立つことを理解しています。

OAuth2では、TweetDeck がサードパーティ アプリケーションであり、Twitter と Facebook がリソース サーバーであり、ユーザーがリソース オーナーであることを意味します。

私の質問は、TweetDeck がリソース所有者に代わってリソース サーバーにアクセスすることに関するものではありません。

私の質問は、TweetDeck が独自のデスクトップ アプリ/モバイル アプリ/Web アプリの認証をどのように処理するかということです。3 つのタイプすべてで、ユーザーは自分の TweetDeckユーザー名/パスワードを使用してログインする必要があるからです。

webapp の場合は、簡単です。TweetDeck は、古き良きサーバー セッションとブラウザー Cookie を使用して、アプリケーション/認証状態と、HTTPS 経由の単純なログイン フォームを維持している可能性があります。

私の主な質問は、デスクトップアプリ/モバイルアプリはどうですか?

TweetDeck も独自の認証に OAuth2 を使用していますか? そうでない場合、それは何を使用しますか?

もしそうなら、それはResource Owner Password Credentials Grantですか? そうでない場合、どのタイプの 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 に答える