上の続き
OAuth が使えるならサーバ同士で直接データをやり取りすればいいのに、わざわざクライアント側でやる必要あるの？というツッコミだと理解しました。僕もそれほどちゃんと考えていなかったので、この機会に考えてみました。
- 負荷軽減 … Consumer 側に負荷をかけたくない場合。 Consumer が Provider 側に接続するためのオーバーヘッドを User に代行させる。
- Provider が提供する WebAPI の制限 … Google Search API が JavaScript だけの提供になったように、 WebAPI として JavaScript のみを提供する場合
例えば、 GMail のような Web メールのサービス提供者が、アドレス帳を JavaScript の WebAPI として提供するような場合を考えました。 SNS のサービス提供者が OAuth の Consumer になって、 SNS の招待状を送りたい相手をアドレス帳から選んでもらう。ここまでは JavaScript で実行して、選択後のアドレスだけを Consumer に送るような場合だと、クライアント側のマッシュアップもありえるのかなと思いました。まぁ、 OAuth の Signature を生成するのは Consumer なので、負荷軽減の効果は少し微妙ですが。
クロスドメインのセキュリティ問題を OAuth で解決する, OAuth のアイデアに kazuho さんからツッコミをいただいた, それ OpenAuth で (ry - まちゅダイアリー(2007-12-07)
早速ありがとうございます。
例に挙がっている特定のメールアドレスをエクスポートするような機能の場合は、OAuth を使わなくても クロスドメイン通信とアクセスコントロール - snippets from shinichitomita’s journal で言及されている AOL OpenAuth のように、iframe でメールアドレスを選択させて、その結果を親フレームに返すようにすべきだと思いました。 (この場合、言うまでもないことだけれども、メールの選択 UI を CSI で Consumer の HTML 上に構築してはいけない) OAuth のような権限委譲の仕組みを用いる意味が大きいのは、いちいちユーザーの許可を求めずに Consumer がデータソースにアクセスすべき場合だと思います。
また、Google Search API が JavaScript のみの提供となったのは、サードパーティのウェブサービスが Google Search の成果を蓄積して再利用するのを防ぎたいという理由からだと思いますが、「ユーザーのデータ」についてそのような囲い込みを行うというのは、考えにくいように思いました。
自分が思いつく範囲で言うと、たとえば、有料でデータを販売しているサービスが、サードパーティにさまざまなグラフ表示機能をつけてほしい、と思った場合に OAuth + Client-side Mashup は使えるのかもしれないとは思います。でもこれは、とってもニッチ...
ただ、自分が思いつかないことと市場が存在し得ないこととの間には100億光年くらいの距離があるので、そのような技術が検討され、公開されるのであれば、それはいいことだと思います。
※10:31 下線部追記
