今までもちょこちょこ考えていたりしてたけど、twitterで関係者の人たちと話したのでもう一回整理しておきます。
ここでいうY!OAuthとはYahoo!IncのOAuth仕様のことを表します。
■ Y!OAuthの特徴
- OAuth Session Extensionという拡張仕様を導入
http://developer.yahoo.com/oauth/guide/oauth-auth-flow.html
http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html
説明は省略します。
■ この拡張使うOAuthがこのままOpenSocialContainerに使われるとどうなる？
- OAuthのAccess Tokenの有効期限が短い(Y!では1時間)のため、ガジェットが短期間しか使えない
orz
■ 誰が何をすればいい？
- Containerが拡張対応 ≒ Shindigが拡張対応
簡単に言えるけど、結構大変ですねと。
SP側も少し親切にした方がいいと思います。例えば、
- OAuth Session Extensionを使っているSPはそのことをXRDで定義
OpenIDのDiscoveryみたいな感じですね。
OAuthにもDiscoveryのExtensionあったと思うんですが、それとかで定義しておくと、
- 1. ContainerがSPをDiscovery
- 2. その結果からロジックを通常のOAuth CoreなのかOAuth Core + Session Extensionなのか決める
す、すこしは使いやすくなりそうですよね。
この拡張がみんなに使われるようになればコード組み込みも実現されるのかもしれないけどY!系だけじゃな。。。
■ 少し一般的なお話
OAuthのSPがOpen Social Containerから使われるためには、こんなこと考えないといけませんねと。
- そもそもOAuthのConsumerって誰だっけ？
- RSA-SHA1署名への対応 ( + OAuth Key Rotation Extension )
- OAuth Gadget Extensionへの対応
誰がConsumerかって話はagektmrさんのエントリhttp://devlog.agektmr.com/archives/174にもあるように、2パターンあるんじゃないですかと。
- (1) GadgetがConsumer
- (2) ContainerがConsumer
(1)の場合、ContainerはGadget単位でConsumer Key/SecretもしくはRSA秘密鍵の管理をして、SPへのリクエストを作る際に使い分けます。
(2)の場合、Containerが一つのConsumer Key/SecretRSA秘密鍵を使ってSPのリクエストを作ります。
実際にはGadget単位でユーザーにリソースアクセスの許可を求めるので、OAuth Gadget Extensionのxoauth_app_urlでURLをSPに伝えてユーザーへの同意画面に含めてもらうという感じでしょうか。
SP側としては、(1)だと他のOAuthアプリと同様に、ユーザーに対して「このアプリにあなたのデータをアクセスさせるんだよ」と説明できるのでシンプルです。
iGoogleに乗ってるYahoo! Updatesガジェットはこのタイプですね。
(2)の場合はOpenSocialアプリ(今後この拡張が広まれば別だけど)を意識して「ContainerがこいつでアプリのURLはこれです」ってとこをどのようにユーザーに見せたらいいかも考えないといけないような。
あと、AccessTokenのScopeもContainer全体というあたりをどう考えるかとか。
とりあえず、ShindigベースのContainerは(2)のやり方で今後どんどん増えるのであれば、無視はできないでしょうね。
RSA-SHA1については省略。過去の記事を参照してください。
(1)だろうと(2)だろうとRSA-SHA1の署名は実装が簡単そうなのでSPはやった方がいいと思う。
ん、パフォーマンスってどうなんだろう。HMAC-SHA1と比べて重いのかな？
■ まとめ
「あまり他のところが使わない拡張使うと、マイナス？の影響がでることもある。」
この件、今後も相談させてください ＞ Containerの皆様
■ 参考リンク
自分のエントリも並べておこう。
