twitterのOAuth認証について

webアプリで、ユーザー管理するアプリを作りたい。けれども、IDやパスワード、メアド管理までするのは大変だったり怖かったりする。なのでそういう時は、twitterやFacebook等の外部サービスのアカウントにユーザー識別（ユーザー管理）の部分を任せるのが良さそうだったので、OAuth認証について調べてみた。

twitterのOauth認証は、@yusukebeさんの著書

Webサービスのつくり方 ~「新しい」を生み出すための33のエッセイ (Software Design plus)

で丁寧に書かれていたので、読みながら自分なりに理解してみた。 ※解りやすいように例えているので、正確には違う部分が多々あるので注意。

まずは単語の問題。聞きなれない横文字が沢山出て来る上に、文字から動作イメージが浮かびいくいので整理してみた。

~token、~secret

とにかくこの単語が沢山出てくる。要はtoken=ID、secret=Passwordと考えれば分り易い。

コンシューマー〜

アプリ作成者がtwitter社にアプリ毎に登録する。 「公認アプリですよ〜」的な認証の意味合いと考えてみる。

リクエスト〜

ユーザーがアプリ上で「twitterでログインする」をする度に、発生する。このIDがユーザー毎かつ時間軸毎に発生するので、「今、この端末・ブラウザからTwitterアカウントを使ってログイン認証をしようとしてますよ〜」を識別してくれる。 アプリの数×ユーザー数×ログイン回数だけある事になる。 入場整理券ぽい感じ。

アクセス〜

晴れて無事に認証が済むと、httpリクエストのパラメーターとして返される。晴れてログイン後、twitterのデータを利用するときにこれが必要。 「twitter内の情報利用券（何回でも使える）」 ユーザー数だけある事になる。 このIDとパスがどれくらいの時間効力があるのか（半永久的に使えるのか）はちょっと分からない。

ユーザー管理

HTTPの仕組みは、リクエストに対してレスポンスの一期一会の結果出力の仕組みなので、本来「ユーザー毎のログイン中」の様な管理・区別は無い。 なので、ログインしたままの状態を表現する方法の一つに、クライアントブラウザのcookieに一意のID的なものを保存しておいて、リクエスト毎に照合する事によってユーザーの区別をして出力結果を操作して表現する。 たいがいのフレームワークには「セッション管理」機能がついているので、そこで実現する。具体的には、セッションIDにアクセストークンを設定しておけば、ユーザー管理が実現できる。

コールバック

twitterへログイン管理を投げた時（リクエストトークンを投げてアクセストークンを取得しようとした時）の戻ってくるURIを設定しておく。 戻ってくる場所=コールバック。

ちなみに、botプログラムはアプリ製作者が作ったtwitterアカウントがツイートする＝１つのアカウントのリソースしか弄らないので、あらかじめコンシューマーキー登録と同時にアクセストークン、シークレットを１対だけあればよい。（リクエストトークンでリクエストしてアクセストークンを得る流れは不要）

とりあえずやり方が理解できた（はず）なので、これから実際にSinatraでコードを書く。