The Introduction of OAuth WRAP vol.1 : Web App Profile on FriendFeed

OAuth WRAPって知ってますか？

まだ仕様を細かい部分まで読めてないのと、JavaScript Profileなどこれからまだまだ拡張されていく段階のようなので、偉そうに仕様を語るのではなく、今回はFacebookの人たちがFriendFeed上に実装したProviderを使って流れを確認してみます。
ここではWeb App Profileという、3-legged OAuthやYahoo!のBBAuthのような使われ方の部分の実装を確認します。

Python+GAEのサンプルがここにあるのですが、
自分でも一通り確認するために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はこれ。

https://friendfeed.com/account/wrap/authorize

必須のパラメータは以下の通りです。

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を要求します。

https://friendfeed.com/account/wrap/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アクセス)

https://friendfeed-api.com/v2/validate
https://friendfeed-api.com/v2/feed/home

上のほうでユーザーの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とか)