OpenSocialでは、コンテナが外部サーバーとの通信を行う際、または外部サーバーがコンテナと通信を行う際、OAuthを使用して認可を行います。今回はOpenSocialにおけるOAuthについて、現段階でのまとめを書いてみます。
※追記(2008/10/20)：2008/10/4に書いたコチラの記事も必読です。
OAuthって何だったっけ？
OAuthはユーザー、コンシューマ、サービスプロバイダの3者間でデータのやり取りを行うとした場合、ユーザーがコンシューマにクレデンシャル(IDやパスワード)を渡すことなく、ユーザーが所有するサービスプロバイダ上のリソースにコンシューマをアクセスさせるためのものです。
例えばユーザーがGoogle(サービスプロバイダ)のアドレス帳(リソース)をMySpace(コンシューマ)上で利用するシーンを思い浮かべてください。OAuthがなければ、MySpaceにGoogleのIDとパスワードを預けなければならなかったものが、OAuthを使うことで、ユーザーが直接Googleと認証のやりとりを行い、MySpaceにGoogleのID/パスワードを渡すことなく、アドレス帳のデータをMySpaceに渡すことができるようになります。
2種類のOAuth
さて、そんな便利なOAuthですが、OpenSocialで利用されるものには2種類あります。
OAuth Core
OAuth Coreでは、先程説明したように、ユーザー、コンシューマ、サービスプロバイダの3者間でやり取りを行います。ベーシックなものですので、詳細についてはこの辺りを参考にしてください。
OAuth Consumer Request
一方OAuth Consumer Requestは、OAuthの仕様からユーザー認証部分を除き、コンシューマとサービスプロバイダのやり取りにフォーカスした仕様で、一般に”two-legged OAuth“と呼ばれます。これはコンシューマとサービスプロバイダの信頼関係だけで、ユーザーによる認証を伴わない仕様のため、コンシューマがサービスプロバイダからパブリックな情報を取得したい場合に利用するケースが想定されます。(追記 2008/10/30: この情報は正確ではありません。改めて訂正記事を書きます)
ちなみにOpenSocial v0.7ではOAuth Coreの利用は仕様に含まれておらず、このtwo-legged OAuthを利用することになっています。OAuth Coreが利用できるのはOpenSocial v0.8以降での話になります(もちろん、two-legged OAuthも利用できます)。
OpenSocialにおけるOAuth利用パターン
OpenSocialでOAuthを利用する形態として、さらに2通りが考えられます。
ガジェットが外部サーバーとやり取りを行うOutbound OAuth
ここでは仮にOutbound OAuthと呼びます。type=”html”で作られたガジェットが、SNSコンテナをプロキシとしてコンシューマの役割を果たし、サービスプロバイダとなる外部サーバーとmakeRequestで通信を行うケースです。
外部サーバーがコンテナとやり取りを行うInbound OAuth
ここでは仮にInbound OAuthと呼びます。コンシューマとなる外部サーバーがサービスプロバイダであるSNSコンテナのRESTful APIを叩くケースです。type=”url”のガジェットが外部サーバーを通してSNSコンテナのRESTful APIを叩くケースもこれに該当します。
OAuthの利用に必要なもの
OAuthの利用には前提条件がいくつか存在します。細かい仕様は別途調べていただくとして、事前に必要な条件が下記になります。
- コンシューマが、サービスプロバイダの発行する以下を事前に知っていること。
- コンシューマキー(consumer_key)
- コンシューマシークレット(consumer_secret)
- コンシューマが、サービスプロバイダとOAuthのやり取りを行う以下3つのURLを知っていること
- サービスプロバイダのリクエストトークンURL
- サービスプロバイダのアクセストークンURL
- サービスプロバイダの認証URL
※追記(2008/10/20)：コンシューマシークレットについては、署名方式がRSA-SHA1の場合、必須ではありません。詳しくはコチラ。
OAuth利用パターンごとにどのようにしてこの条件をクリアするかを検証してみます。
Outbound OAuthのケース
ガジェットが外部サーバーとやり取りを行うケースですので、まずはガジェット開発者がSNSコンテナにコンシューマキーとコンシューマシークレットを登録します。ですが僕の知る限り、まだOutbound OAuthを実装しているSNSはありません。なので、ここでは何かしらの手段を用いて(SSLページでFormを使って投稿等)、コンシューマキーとコンシューマシークレットをコンテナに渡したものと想定してください。(今後順次、これを実現する方法は登場するものと思われます。)
次に、サービスプロバイダの各種URLを渡す必要がありますが、v0.8ではガジェットXMLで渡すよう規定されています。OAuthをModulePrefsの中に作成してください。
<oauth>
<service name="google">
<request url="https://www.google.com/accounts/OAuthGetRequestToken?scope=http://www.google.com/m8/feeds/" />
<access url="https://www.google.com/accounts/OAuthGetAccessToken" />
<authorization url="https://www.google.com/accounts/OAuthAuthorizeToken" />
</service>
</oauth>
OAuthは必ずしも1つのサーバーとやり取りするとは限りませんので、Serviceを追加することで複数をサポートすることができるようになっています。Service@nameで使い分けることが出来るようになっていますので、必要に応じてmakeRequestのopt_paramsに下記のパラメータを加え、サービスを指定してください。
gadgets.io.RequestParameters.OAUTH_SERVICE_NAME
サービスプロバイダとOAuthのやり取りを行うURLについては、XRDS-Simpleによって解決する方法もありますが、こちらについては別の機会にまとめてご紹介します。
Inbound OAuthのケース
外部アプリケーションがSNSコンテナのRESTful APIにアクセスする場合になります。これはまさに、FacebookのFacebook ConnectやMySpaceのData Availability、GoogleのFriendConnectに該当するもので、まだ実験的な段階にあると言えるものです。
コンシューマキーとコンシューマシークレットですが、SNSコンテナ上でアプリケーションを登録することで発行されます。それをディベロッパがメモ/コピペしてコンシューマとなるサーバーのコードに埋め込みましょう。URLについては、単純にヘルプページを見る方法と、XRDS-Simpleによるオートディスカバリを行う方法が考えられます。
まとめ
今回は大まかな話を書きましたが、次回は実際にMySpaceのData Availabilityを使ってOAuth認証を行い、データを取得するところまでを試してみたいと思います。
