OAuth認証
twitterのOAuth認証は難しい。私が何も分かっていない中で、完全な手順を網羅したブログを探せども探せどもないのだから、解決は難しい。あきらめるか、腹をくくって、一から情報を自分のものにしながら進めるかのどちらかしかない状態だ。暇ではないが、プログラムが出来るか否かというのは、今後非常に重要だと僕は最近やっぱり思っている。営業は大体できるようになった。アイデアは考えるのはタダで、考えるのも好きな方だ。あとは語学力とプログラム能力なのだ。語学はそりゃやるとしても、プログラムは腹をくくらないと出来ない。あと５年で３４歳だ。それまでにプログラムもプロ並みになっておこう。ということで、今日は一からOAuth認証を倒すために、コツコツコツコツと調べていきたいと思います。急がば回れの精神で進めたいと思います。
http://www.atmarkit.co.jp/fsecurity/special/106oauth/oauth02.html
上記はOAuth認証のプロトコルのフローを説明している。大きく３つに分けられるようだ。
①コンシューマ登録、②リクエストトークン要求とユーザの同意確認、③アクセストークン要求とAPI接続
①コンシューマ登録はtwitterの場合分かりやすく、解説ページも至る所にあるので問題ない。それに作業が完全に分離されている。問題は、②③の流れがPHPのOAuth認証サンプルコードのどこにあたり、サンプルコードの後でどういったプログラムを組む必要があるのかについて、全く認識／想像ができない点だ。よって、②③の流れをしっかりと把握しつつ、サンプルコードのソースの意味を把握する必要がある。今日はこれに３時間使おう。３時間じゃ終わらないだろうが。。
（1） ユーザーはコンシューマのサービスを利用するために、Webブラウザでコンシューマにアクセスする。
（2） コンシューマはユーザーからサービスプロバイダのリソースを利用する意思を確認した後、サービスプロバイダに接続して「リクエスト・トークン」の発行を要求する。この際、コンシューマ・キーや、コンシューマ・シークレットを使って生成したサイン値などをパラメータとして渡す。
（3） サービスプロバイダはコンシューマから送られてきた値を確認した後、未承認の（Unauthorized）リクエスト・トークンをコンシューマに返す。
（4） 未承認のリクエスト・トークンを受け取ったコンシューマは、リクエスト・トークンにユーザーの承認を取るために、未リクエスト・トークンとともにユーザーをサービスプロバイダにリダイレクトする。
（5） サービスプロバイダはまずユーザーにログインを要求し、クレデンシャル（ユーザーIDやパスワードなど）を確認する。ユーザー認証が成功したら、ユーザーにコンシューマがアクセスするユーザーリソースの内容と条件を表示し、同意の確認を促す。
（6） ユーザーの同意が取れたら、リクエスト・トークンを「承認（Authorized）」にして、ユーザーとともにコンシューマへリダイレクトして返す。ユーザーが同意しなかった場合は「拒否（Denied）」にして返す。
（1） コンシューマは承認済みのリクエスト・トークン、コンシューマ・キー、コンシューマ・シークレットで生成したサイン値などをパラメータとしてサービスプロバイダに送って、「アクセス・トークン」の発行を要求する。
（2） サービスプロバイダはコンシューマから送られてきたパラメータの値を確認し、問題がなければ、APIへの接続に必要なアクセス・トークンとそれを署名するのに利用する「トークン・シークレット」をコンシューマに返す。
（3） コンシューマはアクセス・トークン、コンシューマ・キー、トークン・シークレットで生成したサイン値などをパラメータとして送り、ユーザーリソースの入り口であるAPIに接続を要求する。
（4） サービスプロバイダはそれぞれのパラメータの値を確認し、問題がなければ、APIの応答データをコンシューマに返す。以後、サービスプロバイダがアクセス・トークンに付与した条件（リソースの種類・期間など）に応じて、コンシューマは（3）を繰り返してAPIを経由してユーザーのリソースにアクセスする。
