twitterでOAuthを使う方法（その１：認証まで）

OAuthって結構難しいと思われてるようですが、難しいというよりは、『ややこしい』です（苦笑）

そんなわけで。
手順毎に順番に説明をしようと思います。
※2009/09/23 説明の図（手書きでごめんなさい）追加しました。

●語句の説明
・サービスプロバイダ(service provider)・・・サービスを提供しているところ。この場合、twitter。
・ユーザ(user)・・・サービスプロバイダに登録していて、そのサービスを利用している人。
・コンシューマ(consumer)・・・サービスを提供しているところに、ユーザにかわって、そのサービスに対してアクセスする第三者。サードパーティ、とでも言うべきでしょうか。要は、この記事を見て「何か作ってみたい」という、あなたです。

●ステップ０：まずは登録→Cosumer Token/Secretの取得
まずは、アプリケーションの登録作業です。ある程度かたちになってからのほうが望ましいですが、ぶっちゃけ適当でかまいません（笑）
OAuthの仕様書では、この取得に関するプロトコルは定めておりません。
サービスプロバイダとコンシューマの間で直接やりとりしてね、ってことです。


ここから登録できます→http://twitter.com/apps/new
1.「設定」
2.「Connections」
3.右側の「Developers can edit the registration settings for their applications here.」
4.一番下に「Register a new application »」とあるので、こいつをクリック！
と行けば、登録画面に行けます。
たまにくじらさんが出ますが、そのときはリロードしてください。

登録に必要な項目は以下の通りです。
・Application Icon ・・・アプリケーションのアイコンです。アイコンはわりと重要です。
・Application Name ・・・アプリケーション名称です。
・Description ・・・アプリケーションについての説明。あまり長く書けないので簡潔に。
・Application Website ・・・ アプリケーションのサイト。説明してるサイト、もしくはホームを書きます。
・Organization ・・・ 作ってる組織。自分の名前（ニックネーム）でいいでしょう。
・Website ・・・ 作ってる組織のウェブサイト。twitterやってるなら、プロフィールのweb欄と同じで大丈夫。
・Application Type ・・・アプリケーションの種類です。
　　・Cient・・・クライアントアプリケーション。
　　・Browser・・・ブラウザベースで使用する場合。webアプリの場合はこちらでOKです。
・Callback URL・・・認証に成功したときにtwitterが戻すURI
・Use Twitter for login・・・twitterのidを認証に使用する場合はチェック
　　※twitterのidを使って自分のサービスで認証しないときは、チェックする必要はありません。

登録すると、以下の情報がもらえます。
・Consumer key ・・・コンシューマを識別するキー
・Consumer secret ・・・コンシューマの秘密鍵
・Request token URL ・・・ Request token の処理に用いる URI
・Access token URL ・・・ Access token の処理に用いる URI
・Authorize URL ・・・ 認証に用いる URI (今回は使用しない )

登録は以上です。
Consumer key , Consumer secret は、今後の処理で必要なので、忘れずに控えておいて下さい（といっても、自分の作ったアプリ一覧画面で出るから大丈夫だけど )

これからが、実際の「ユーザによる認証」のプロセスとなります。

●ステップ１：ユーザから、サービスプロバイダへのアクセスを「許可したい」と、コンシューマにリクエストが来る
あなたが提供しているサービスに対して、twitterのOAuthを使ってアクセス許可を出したい、というリクエストがきます。

●ステップ２：サービスプロバイダへ利用許可を求める (6.1)
はい、ここからが本番です。
コンシューマ(要は、あなた)は、サービスプロバイダへ「request token」を投げます。
必要な、固有の情報は以下のとおりです。
・コンシューマキー ( oauth_consumer_key )
・ユーザが承認したときに（最終的にコンシューマの使用を許可させるために）差し戻すURI ( oauth_callback )
あと、必要なもの
・OAuthのバージョン (oauth_version )
・タイムスタンプ ( oauth_timestamp )
・当該アクセスに対して、一意性を表す文字列( oauth_nonce )
・署名のプロトコル( oauth_signature_method )
・署名( oauth_signature )
※署名に関してはややこしいので、あとで説明します。

以上の情報を添えて、サービスプロバイダへrequest tokenを投げます。
コンシューマキーと署名の情報が合致した場合、サービスプロバイダは以下の情報を返します。
・oauth_token ・・・ユーザのトークン（仮）
・oauth_token_secret ・・・ ユーザの秘密鍵
・oauth_callback_confirmed ・・・ OKだった場合これが「true」になる
　なお、そもそも失敗した場合、HTTPプロトコルの「401」がかえってきますので、成功の可否はこちらで見るべきです。

無事に情報がかえってきた場合、コンシューマ（つまり、あなた）は、ユーザに対して、サービスプロバイダの認証用URIに行くように指示（リダイレクト）してください。


twitterなら、 http://twitter.com/authorize
引数には、さきほど返してきた「oauth_token」を入れます。
oauth_tokenに「hogehoge1234」とついていた場合、
　http://twitter.com/authorize?oauth_token=hogehoge1234
というURI、となります。
これにより、サービスプロバイダ(この場合、twitter)の認証画面へ飛びます。

●ステップ３：サービスプロバイダによる許可 (6.2)
認証画面に行くと、「このアプリケーションへの使用許可を出しますか？」という画面になります。
ユーザはここで「Accept（許可する）」を選択します。
すると、サービスプロバイダはユーザに対して、ステップ２でサービスプロバイダに与えた「oauth_callback」へ、行くように指示します（リダイレクト）。


このとき、以下のパラメータを付与します。
・oauth_token・・・ステップ２で戻ってきた oauth_token
・oauth_verifier・・・ユーザがOKしたということを示す(verify) キー

●ステップ４：コールバック→アクセストークンの取得 (6.3)
callbackされたリソースは、oauth_token/oauth_verifierを使って、ステップ２のユーザが「本当にリクエストしてきた」ということを証明するため、もう一度、サービスプロバイダへアクセスします。
・oauth_consumer_key ・・・ コンシューマのキー
・oauth_token ・・・ステップ２で戻ってきた oauth_token（ユーザごとの、ね）
あと、必要なもの
・OAuthのバージョン (oauth_version )
・タイムスタンプ ( oauth_timestamp )
・当該アクセスに対して、一意性を表す文字列( oauth_nonce )
・署名のプロトコル( oauth_signature_method )
・署名( oauth_signature )
※署名に関してはややこしいので、あとで説明します。
※この時点で、oauth_token_secret (ユーザごとの秘密鍵) が存在することを忘れないでください。

このリクエストを投げると、ユーザからのリクエストが正式なものとして扱われ、以下の情報がかえってきます。
・oauth_token ・・・ 『正式の』アクセストークン
・oauth_token_secret ・・・『正式の』アクセストークン秘密鍵

コンシューマは、この２つの情報を保持して、当該ユーザの情報とリンクさせて、サービスプロバイダへのアクセスに使用します。

これで、すべての認証プロセスは終了です。

●最大の問題：署名
一番厄介な部分がここだと思います。

■signature base string ... 署名の対象となる文字列
とりあえず、単刀直入にこんなかんじになります。
・リクエストメソッド(GET/POST等)
・リクエストを投げるURI (?以降は含まない)
・リクエストに絡む情報すべて(※1)
この３つを「&」で結びます。
こんなかんじ。

POST&http%3A%2F%2Fexample.net%2Fapi.php&oauth_consumer_key=dpf43f3p2l4k3l03%26oauth_nonce=kllo9940pd9333jh%26oauth_signature_method=HMAC-SHA1%26oauth_timestamp=1191242096%26oauth_token=nnch734d00sl2jdk%26oauth_version=1.0

リクエストに絡む情報すべて(※1)ですが、
・リクエストヘッダ
・POSTメソッドによる本体
・GETメソッドのquery_string
すべてを、「&」で結んだあとに、一括してurlencodeします。
つまり、3つ目の情報においては
・「&」「=」はurlencodeの対象になる
ので、signature_base_stringの中には「&」が2個だけ存在します。

このsignature base stringに対して、指定したアルゴリズム(twitterなら、HMAC-SHA1 )で、処理したあと、base64エンコーディングします(改行コード等は取り除く)

これで、署名は完成です。

もし、何か間違いがありましたら、気軽にご指摘いただければな、と思います。

参考文献
・OAuth core 1.0 ・・・オフィシャル
・Yahoo!デベロッパーネットワーク - OAuth - フロー
・APIアクセス権を委譲するプロトコル、OAuthを知る − ＠IT