OAuthには鍵がいっぱい登場します。この鍵についての理解を深めるため社内勉強会の講義の内容を一部まとめて公開しておきます。
登場するアクターの解説
- 特に解説不要かもしれませんが、念のため。
Consumer
- ServiceProviderに依存してアプリケーションを提供する主体
- メリット
- Service Providerの会員基盤を利用できる
- 自前のアカウント管理機構を用意しなくてよい
- Service ProviderのID、パスワードをConsumerのDB等に可逆形式で保存する必要がない
User
- 実際にアプリケーションを利用するユーザー
- メリット
- 最初にアクセスするのはConsumerの画面
- ID/PASSを渡さなくて良い
- 会員登録も比較的しなくてよい。簡単。
- Consumerへ利用許可を与えてもあとからServiceProviderかに拒否できる
ServiceProvider
- 認証API(OAuth)や各種API(REST等)を提供
- メリット
- 外部性を生かしたサービス(Twitter APIs等)をセキュアに提供
- ユーザー単位ではなく利用権限単位での移譲制御できる
- 不正なConsumerについて利用制限が容易にできる
登場する鍵。
- 発行単位に注意。
Consumer keyとConsumer secret
- Cousumer <=> ServiceProviderとの認証に必要。
- Cousumerを特定するのもこの鍵。
- 1 Service Provider単位で発行。
Request TokenとRequest Token Secret
- 下記のAccess tokenとAccess token secretを(初回)取得するのに必要な鍵。Consumer Key、Consumer secretから作成される。Access tokenとAccess Tokenを取得するためにUserの認証リクエスト毎に作成される。
- 最初の認証開始リンク作成時に、Request Tokenを発行し、ServiceProviderへのリンクを作成する
- Service ProviderからCallbackがあった場合は、リンク作成当時のRequest TokenとRequest Token Secretを用いて認証し、下記のAccess Tokenを作成する。(改ざん防止。署名にはランダムな数字であるnonceとUnixTimeStampを含める)
- 1認証要求単位で発行。
Access tokenとAccess token secret
- UserがConsumerを経由してServiceProviderのAPIアクセスをする認証に必要
- 1 User単位で発行。
APIをたたく時には鍵は2系統だけでよい。
- Access tokenとAccess token secret取得するのにRedirectがたくさん発生する。
- その後APIたたくのはConsumer keyとConsumer secret、Access tokenとAccess token secretだけあればよい
- いったんUser => Cousumer => ServiceProviderの流れが認証できればその後APIたたくのはConsumer keyとConsumer secret、Access tokenとAccess token secretだけあればよい
- ConsumerはそのDB等にユーザ単位でAccess tokenとAccess token secretだけ保存しておく
- Cousumer keyとCousumer secretはソーシャルアプリ(?)登録時に登録され不変
- Access tokenとAccess token secretは上記User => Cousumer => ServiceProviderが認証できれば一応不変。(あとからServiceProviderから拒否できる)この2つで誰なのかも特定できる。
参考情報
本エントリーを読んである程度理解された場合、参考としてYahoo!のシーケンス図withパラメタが非常に参考になるためこちらもぜひご確認ください。Yahoo!さん素晴らしい。
