OAuthをごそごそやってたのは twitter がそのうち Basic認証じゃなくて OAuthをAPIのクチにする、というの読んだから。

OAuthのわかりやすい解説は他の有用なサイトにまかせるとして、素人のわたしの理解をメモる。

やろうとしているコト。

現状。

1)縦書きtwitter（わたしの作ったtwitterを利用するサイト）がある。

2)縦書きtwitterは現状ではユーザーにtwitterのIDとPASSを入力してもらって、そのユーザーのタイムラインを取得、表示している。

※入力してもらった情報はユーザーのクッキーに保存。twitterに対してはBasic認証で繋いでいる。

この（2）の部分を、今後twitterが推奨するという、OAuthでの認証にしてみたい。

ざっくり大雑把な理解で流すけど。

1)縦書きtwitterにユーザーがアクセスする。

2)縦書きtwitterは、twitter本体に対して、縦書きtwitterは登録してありますよ、とお伺いをたてる。

3)twitter本体が、おう、お前久しぶりやな、ということがわかれば、ユーザーをこっちに寄こしなさい、ということで、ユーザーを twitterにリダイレクトする。

4)ユーザーは twitter に飛ばされて、そこでIDとPASSを入力して「承認」すると、ふたたび縦書きtwitterに戻される。

5)ユーザーは、twitterからもらう アクセスのためのtoken （IDみたいなもんだ）と、tokenを含めたアクセスを正しく認識するためのtoken_secret（パスワードみたいなもんだ）を持って戻ってくることになる。

6)縦書きtwitterは、ユーザーのtokenとtoken_secret＝IDとパスワードをどこかに保存しておいて、ユーザーに縦書きtwitterを使ってもらう。

※保存するのはたぶんクッキー。DBに保存したら、今度はそのIDとPASSがだれのものか、というログインが必要になるしねえ。

一応、OAuthで TL を取得したり、つぶやきを投稿したりできるようにはしたけど。はたして、これ、本当に安心で便利なシロモノなのか、そこんとこがまるで理解できない。

Basic認証は、IDもパスワードも平文で流れるのでセキュリティに問題があるのはよくわかる、けど。Basic認証にしろ、OAuthにしろ、少なくともアクセスしている間は、IDとパスワードをどこかに保存しなきゃいけない。この穴はBasic認証だろうとOAuthだろうと同じじゃないのか。見えないIFrameに仕込まれる程度のチャチなクッキー引っこ抜きに引っかかって「なりすまし」被害に合うのは防げない、ような気がする。

ユーザーにしてみれば、yhooなりmixiなり、ひとつのIDとパスワードを使いまわしできるので管理がラク、ってだけだったら（セキュリティ的に画期的になにかが変わったわけでもなさそうな）OAuthなんてこんな「ややこしい」手順を踏まなきゃいけないメリットは感じないんだよなあ。

OAuthの良さを誰か教えてくだされ～。