OAuth Gadgets Extension

OAuth Gadgets Extension

OpenSocial ContainerにOAuthに対応したAPIを提供しようと考えたときに、RSA-SHA1 SignatureとOAuth Gadgets Extensionが重要になると思っています。

RSA-SHA1については結局そんなに難しそうではなさそうということで、今回はOAuth Gadgets Extensionの仕様を調べてみて使いどころを考えてみます。

■ Spec

Abstractにはこう書いてあります。

Sometimes, the consumer application plays host to a large number of smaller applications ("gadgets").
In that case, the consumer application may make OAuth requests on behalf of one of its hosted gadgets.

This draft specifies a mechanism in which a consumer can express on behalf of which of its hosted gadgets OAuth requests are being made to a service provider.

OpenSocial Gadgetから外部へのAPIアクセスの形式そのものです。
3. Definitionsの部分は次のようになります。

  • Consumer Identity

ConsumerKey,ConsumerSecret,RSA pubkeyなどConsumerを識別するために必要な情報です。

  • Gadget Server

GadgetをホストしているOAuth Consumer,今回の場合、OpenSocial Containerのことです。

  • Gadget

OpenSocial Gadgetのことです。
特定のURLに置いてあってというところはOpenSocialでいうところのXMLのURLですね。
XMLにはConsumer Identityを含まず、代わりにOpenSocial ContainerがOAuth Proxyを利用してOAuthの処理をするときに自分のConsumer Identityを利用します。

では、OpenSocial ContainerがOpenSocial Gadgetの代わりにOAuth対応のAPIを利用する際の処理はどうなるのでしょうか。
4. The Gadgets Extension Parameterには、こう書いてあります。

GadgetのURLをxoauth_app_urlというパラメータとしてOAuthのRequestに含む

Consmerはxoauth_app_urlパラメータを全てのRequestに含めなければなりませんしか書かれていません。
仕様はこれで十分なのでしょうか?SP側の処理について記述されていません。
SP側の使いどころ、実装方法を考えてみます。

■ Best Practice

上記の仕様では、あるOpenSocial Container上の複数のGadgetからSPに送られるRequestは、次のような特性を持つことになります。

  • ConsumerはOpenSocial Containerであり、consumer key,signature作成時の秘密鍵、検証のための公開鍵は共通
  • xoauth_app_urlパラメータがある場合には、それでOpenSocial Gadgetを識別可能

SP側はこのようなRequestをどのように処理すべきでしょうか？
ポイントは「OpenSocial Container＋OpenSocial Gadgetの組み合わせ」として扱うことだと思っています。

  1. 「OpenSocial Container＋OpenSocial Gadget( + User )の組み合わせ」に対してToken発行を行う
  2. UserへのConsent Pageを出す場合には「OpenSocial Container＋OpenSocial Gadgetの組み合わせ」を明示

ちなみに、既存のOAuth SPであるGoogle,Yahoo!のToken発行対象については、次のようになっています。

  • Yahoo! : Consumer( + User )に対して発行
  • Google : Consumer + Scope ( + User )に対して発行

Googleは組み合わせにxoauth_app_urlを追加してやればいけそうだけど、OAuthのRequsetにScopeが必須なのはOpenSocial Containerからのアクセスに影響はないのだろうか？
Yahoo!みたいなつくりにしているところにxoauth_app_urlとの組み合わせを入れ込むのはけっこうしんどいような。。。

■ まとめ

とりあえず、OpenSocial ContainerにOAuth APIを提供するために知っておくべき機能、仕様を調べました。

今回やってて気になったのは、Allen Tomが作ったYahoo! Update API on iGoogleです。
Yahoo!はRSA-SHA1に対応していないはずだし、フローや画面を見る限り、個別にConsumerKey,ConsumerSecretをやりとりしたのでしょうか。
また、Yahoo!のOAuthはCore 1.0に従って使うとAccess Tokenが1時間で無効になる。しかしGadgetは普通に使えています。
ということは、iGoogleのOAuth ProxyはYahoo!のOAuthが採用しているOAuth Session Extensionにも対応しているのでしょうか？

OAuth SPとOpenSocial Containerがこっそり連絡を取り合ってHMAC-SHA1でやりとりできる状況を作ってやるのもいいとは思うんですが。。。
なんか、気分的にOpenじゃないですよね？というあたりが気になりました。

DOMAIN ERRORで説明されているOAuth Key Rotation Extensionについては。。。
とりあえず、今回は調べなくていいかなぁと思っていますが、いつか調べます。

agektmrさんのエントリを見ていて思い出しました。
「RSA-SHA1を使うときには公開鍵をConsumer→SPの方向で登録する」ため、
「複数のOAuth SPに対してConsumerKeyだけ使い分ければいい(ConsumerSecret不要)」という点を
前回の内容に入れておけばいいと思って忘れていました。

OAuthのSPがGadget Extensionに対応したら、OpenSocialでなくても同じようなProxy体系でアクセスするしくみに導入できそうです。
例えば、id:shinichitomita さんのOAuth CrossDomain JavaScript Proxyとかどうでしょう？