2009/12/28
■[OAuth]The Introduction of OAuth WRAP vol.1 : Web App Profile on FriendFeed
OAuth WRAPって知ってますか?
- Implementing the New OAuth WRAP - Facebook開発者
- OAuth WRAP support in FriendFeed for feedback - Bret Taylor’s blog
- OAuth / OAuth WRAP
- OAuth WRAP WG | Google Groups
- OAuth WRAP - Codin’ In The Free World
まだ仕様を細かい部分まで読めてないのと、JavaScript Profileなどこれからまだまだ拡張されていく段階のようなので、偉そうに仕様を語るのではなく、今回はFacebookの人たちがFriendFeed上に実装したProviderを使って流れを確認してみます。
ここではWeb App Profileという、3-legged OAuthやYahoo!のBBAuthのような使われ方の部分の実装を確認します。
自分でも一通り確認するためにphp+さくらインターネットで実装!
http://r-weblife.sakura.ne.jp/php-ff-oauth-wrap/
さっそく、シーケンスから。
ここでは以下のような処理が行われています。
- (1) : Clientがユーザーを認可用URLに送る
- (1'): ユーザー認可後、Verification CodeをClientに渡す
- (2) : Access Token/Refresh Tokenを要求
- (2') : Access Token/Refresh Tokenを返答
- (3) : Protect Resourceにアクセス(APIアクセス)
- (3') : APIレスポンス
既存のOAuth Core 1.0a + OAuth Session Extensionを使ったYahoo!のOAuthに近い気がしますが、少し異なっています。
- Request Tokenを使わない
- Signatureを使わない
- タイムスタンプも使わない
実装は非常に楽でした。
では、処理単位でパラメータを見ていきます。
■ (1) : Clientがユーザーを認可用URLに送る
URLはこれ。
必須のパラメータは以下の通りです。
- wrap_client_id : OAuthでいうConsumer Key
- wrap_callback : 認可後の戻り先URL
オプションとして、以下の値もつけられます。
- wrap_client_state : AuthZ Serverから認可後にClientへ引き回される値
ClientはCookieの識別子とかをこれに指定しておけば、戻った時に正しい遷移で戻ってきたかをある程度確認できますね。
とちゅうで挟む画面はこんな感じです。
■ (1'): ユーザー認可後、Verification CodeをClientに渡す
認可が完了すると、以下のパラメータがついてwrap_callbackで指定したURLに戻ってきます。
- wrap_client_state : 上で説明した値。
- wrap_verification_code : 認可が完了したことを示す文字列
Access Token/Refresh Token取得時に利用します。
■ (2) : Access Token/Refresh Tokenを要求
リソースアクセスに必要なAccess Tokenを要求します。
OAuthでいうとRequest Token,VerifierとAccess Tokenを交換するところです。
- wrap_client_id : OAuthでいうConsumer Key
- wrap_client_secret : OAuthでいうConsumer Secret
- wrap_callback : 認可要求時のCallback URL
- wrap_verification_code : 受け取ったVerification Code
署名は不要です。
HTTPSなので、wrap_client_secretはそのままリクエストに含まれてもいいって感じでしょうか。
■ (2') : Access Token/Refresh Tokenを返答
- wrap_access_token : OAuthでいうAccess Token
- wrap_refresh_token : OAuth Session ExtensionでいうOAuth Session Handle
現在、FriendFeedのAccessTokenはずっと有効でExpireしませんが、仕様ではこれらのTokenの有効期限も返されることになると思います。
OAuth Session Extensionと同様に、Access Tokenの有効期限は短く、Refresh Tokenの有効期限は長くなるでしょう。
■ (3) : Protect Resourceにアクセス(APIアクセス)
上のほうでユーザーのtype,id,nameが取得できます。
下のほうでHome Feedがとれます。
必要なWRAP用パラメータはこれだけです。
- wrap_access_token
■ (3') : APIレスポンス
省略
□ 考察
- Request Tokenが
- 「SSL(HTTPS)でやるからSignatureイラネ」って感じで実装は簡単
- 大量アクセスによるアタックとかされたときのAuthZ ServerやProtect Resource側の対策がキモになりそう
もし、今後TwitterみたいなHTTPで全部やってたとこがこれ使ったらSSLの処理が増えてとんでもないことになりそう。。。
□ ToDo
別途、仕様のまとめドキュメントを用意中。
ただ、ある程度決まって仕様のドラフトがもう少し更新されてからエントリを書く予定。
- 仕様まとめドキュメント
- 他のProfile(JavaScriptとか)
- 7 http://fastladder.com/reader/
- 7 http://www.google.co.jp/search?q=oauth_verifier&lr=lang_ja&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ja-JP-mac:official&client=firefox-a
- 4 http://twitter.com/
- 2 http://b.hatena.ne.jp/add?mode=confirm&title=PHP%u3092%u8AAD%u3093%u3060%u3053%u3068%u3042%u308B%u4EBA%u306E%u305F%u3081%u306EOAuth%u306ESignature%u89E3%u8AAC - r-weblife&url=http://d.hatena.ne.jp/ritou/20090912/1252776563
- 2 http://bit.ly/4IUfgp
- 2 http://d.hatena.ne.jp/
- 2 http://d.hatena.ne.jp/t2aki/comment?date=20091231
- 2 http://longurl.org
- 2 http://pipes.yahoo.com/pipes/pipe.info?_id=02db597254ec68550537866a2fca2ce6
- 2 http://twtr.jp/home



