Subscribed unsubscribe Subscribe Subscribe

デスクトップTwitterクライアントアプリでOAuthを使うことの問題点?

Twitter

発端

[連絡] Termtter の OAuth 機能は廃止の予定 - セキュリティ的な理由から #termtter

@jugyo OAuthあまり良くわかっていないですがどういったことが問題になるのでしょうか? ><

@sugyan Termtter のようなアプリの場合、ユーザーのPCに consumer key 等を置かざるを得なくて、それを使えば誰でも Termtter に成り済ませるんですよね #termtter

@sugyan consumer key と consumer key secret を安全に保持する方法が思いつかなかったので OAuth はあきらめることにしました #termtter

これ、どんな問題があるかなぁ RT @jugyo: @sugyan Termtter のようなアプリの場合、ユーザーのPCに consumer key 等を置かざるを得なくて、それを使えば誰でも Termtter に成り済ませるんですよね #termtter

via以下については現時点で簡単に偽装可能。consumer keyをつかってtwitterに攻撃して、consumer key を block される、というあたり?

consumer key をハードコードしてると再発行が面倒か。他にどんな問題があるだろう > consumer keyの流用

現時点での自分の理解

  • アプリケーションはconsumer_keyとかを持つ
  • OAuth対応サービスの、指定されたURLにユーザーを誘導して、認証してもらう
  • ユーザーがそのサービスでアプリケーションに対して認証を行うと、access_tokenが発行される
  • アプリケーションはそのaccess_tokenとconsumer_keyを使ってサービスのAPIを使用することができる

というのがOAuthの仕組みかと。

Twitterの場合

  • 開発者がTwitterでアプリケーションを登録、consumer_keyとかが発行される
    • その際、「Client」か「Browser」かを選択する
  • アプリケーションはconsumer_keyとかを使ってTwitterの認証ページへユーザーを誘導
  • Twitterでユーザーがアプリケーションに対して認証をする
    • Clientの場合、PIN#が発行され、それを使ってaccess_tokenとかを発行できる
    • Browserの場合、指定したURLにコールバックされ、そのrequestパラメータにaccess_tokenが含まれる、のかな?
  • で、得られたaccess_tokenとconsumer_keyを使ってTwitter APIを使用できる

ということになる。

で、

ここで使うconsumer_key、consumer_secretは、Webアプリならサーバ内で保持して漏れないようにしておくことができるのだろうけど、デスクトップアプリの場合、そういうことができない。
スクリプト言語で書かれたものの場合、どうしてもソース内か設定ファイル内に記述することになり、使用者は簡単にそれを知ることができてしまう。バイナリのみの提供で隠蔽していたとしても、おそらくHTTPリクエストを監視してしまえば覗くことができる、はず。


なので、デスクトップアプリでTwitterクライアントがOAuthを使おうとする場合、consumer_keyを隠蔽することができないという問題があるようだ。

consumer_keyが漏れることの問題点

って、なんだろう…
冒頭で挙げられている通り、

  • 他のアプリでそのconsumer_keyを使うことができてしまう
    • とは言えTwitterアカウント持っていれば誰でもoauth_clients作成できるのでそんなことをするメリットは誰にもないとは思うのだけど
    • でもそれが悪用されたりしてそのclientsがblockされてしまうと、他のユーザーが使えなくなる、という危険性がある

というところなのかな。

つまり疑問は

  • consumer_keyをユーザーに知られないようにデスクトップTwitterクライアントを作ることはできないのか?
  • やっぱりconsumer_keyはユーザーには知られないようにすべきなのだろうか?
  • consumer_keyが漏れることの危険性は他に何があるだろうか?

ということ。
誰か詳しい方、教えて下さい ><