« 引き伸ばし機を頂いた | トップページ | Nikon F-601購入 »

2010.08.09

TwitterのデスクトップアプリでOAuth対応しても、全く意味がない。

前から各所で話題になっているのだけど、2010年8月でTwitterのBASIC認証が廃止されるため、OAuthへの移行が推奨されている。
私もTwitterに自動投稿するbotを作っていたので(粒粒bot)、これもOAuth対応したんだけど、あまりのメンドくささと理不尽さにすっかり参ってしまった。しかも、これだけメンドくさいことをしてもOAuthへの移行には全く意味が無いということに気が付いたので、ちょっとここにメモしておきたいと思う。

そもそも、OAuthはWebアプリで使われるということを前提とした認証形式であり、これをデスクトップアプリケーションに適用しようとすると変なことが起こる。
これは、ブラウザ認証が途中で絡むためにCUIなアプリにまで内部Webブラウザを同梱しないといけないという実に筋の悪い点もそうなのだが、それよりも、そもそもOAuthを使うことの意義を全くゼロにしてしまうという点でなお悪い。

TwitterでのOAuthの流れは、大まかに以下な感じだ。
1) Twitterの開発者向けページからアプリを登録すると、consumer keyとconsumer secretが発行される。
2) 一般のアプリ利用ユーザは、このconsumer key/secretを元に、request tokenを生成する。生成したrequest tokenを用いて、Twitter内の認証ページから該当アプリに許可を出す。
3) 許可を出すと、PINが発行されるためこれをアプリに登録する。
4) アプリはPINを元にaccess tokenとaccess secretを取得する。
5) アプリは投稿の際、access tokenとaccess secretで認証。

Webアプリならば、アプリ側でconsumer keyとconsumer secretを持てばいい。当たり前の話だし、これが本来の想定。
しかしこれがデスクトップアプリになると、途端に困ってしまう。アプリの配布物の中に consumer keyとconsumer secret も同梱しないといけないわけだ。そうなると、この同梱したconsumer keyとconsumer secretを使って、全くの第三者が他人のアプリを勝手に騙ってしまうことができる。
特にオープンソースな物の場合は、平文でこれを保存するので誰でも悪用可能だ。事実、たとえば有名なデスクトップアプリ Tween はソース公開されているので、誰でもconsumer keyとsecretを知ることができる。

もちろん、オープンソースにしている時点で作っている方はそれで構わないはずなのだが(例えばBSDライセンスならば、「誰がどう使おうが知らんがな」という立場故に、平文で載せたまま公開している)、これじゃTwitter側が主張している「そのアプリが本物かどうかの確認」という意味でのOAuth使用には全く意味がない。
ユーザがWebに誘導されて許可を出したアプリと、今自分のデスクトップで動いているアプリ。その2つが同一のものだと、一体どこを見て確認すれば良いのか? 「確認できない」が答えなのだ。

というわけで、今回のTwitterのOAuth認証必須という仕様は大きな誤りであり大きなムダである、というのが私の主張。

※全く同じことを考えている方がおられたのでリンク張らせて頂きます:
デスクトップTwitterクライアントにおけるOAuth問題

|

« 引き伸ばし機を頂いた | トップページ | Nikon F-601購入 »

コメント

ややこしいから分かりやすい説明はリンク先を読め。まで読んだ。

投稿: Kan | 2010.08.10 00:28

今日、大井町で、日本で一番うまいつけ麺を食べた。

投稿: ozuma | 2010.08.10 01:16

コメントを書く



(ウェブ上には掲載しません)




« 引き伸ばし機を頂いた | トップページ | Nikon F-601購入 »