Google FriendConnect APIとFacebook Connectという変態たち

遅ればせながら、Google FriendConnect がAPI出しましたね。Google FriendConnect本体がブログパーツ的にウェブに貼付けるものだったので、それ用のガジェット開発キットかなと思ってあつかうと、間違えますね。これ、ぜんぜんガジェット開発者だけの話ではないですよね。

早速えーじさんが記事を書いてます。

サービス提供者にとって，今回公開されたGFCの認証機構は魅力です。OpenIDを使ってすら複雑なサーバー実装を必要とした認証が，HTMLファイルとJavaScriptの設置だけで実現できるのです。認証機能を完全に外部にたよることで，Cookieのパラメータでログイン状態を判断し，さらにそれを認可にも用いることで，サービス提供者は開発の手間を劇的に減らすことができます。

http://gihyo.jp/dev/column/01/social/2009/031801

これが最もすばらしいと思います。もちろん、アイデンティティをコンシューマ側で検証する必要があるなら、最後にサーバ側で問い合わせするので、全くサーバ要らず、というわけではないとおもいますが、単にグリーティングメッセージやソーシャルグラフを表示するくらいなら、ほんとにコピペでできるし、データの書き込みだってできる。

あとは、OpenSocialのAPIをほぼ備えていること。これはとても面白い。OpenSocialのJavaScript APIって、ガジェット内でしか使えないっていう印象があったと思うんですが、こうやって外部サイトでも簡単に使えるようになるなら、わざわざRESTful APIを使ってサーバサイド作る必要はあまりなくなる。もちろん携帯対応とかかなり捨てる部分は多いのでなんなのですけれども、それでもSNS内部に隔離されるよりは全然いいし、JS固有のポータビリティもライトな開発者に味方するに違いありません。

とまあやっとでたAPIなんですが、もうすでにFacebook Connect では一番最初に実現していたことだったりします。逆にFacebookにはウィジットのような即物的なものが無かった訳ですが、それも最近出してきてたりするので、それぞれ優先度やアプローチの違いがでてて面白いですね。

さて、ここまでは前段で、ここから本題。

結局彼らの出しているサービスは、共にソーシャルグラフのWeb世界への流通を目指しているのでしょうが、今のWebの世界ではコストをかけない流通の最右翼はJavaScriptです。数多くの広告／ブログパーツ、そしてGoogle Mapsが普及できたのも、これがJavaScriptでできていたからだ、とも言えるのではないかと思います。実際、サーバを用意せずともコピペだけで実際にWebページが動くので、かなり敷居が下がっているはずです。その意味で、この２者が同じくJavaScriptによるAPIを出していることは、理にかなっています。

ただ、世の中で、JavaScriptによるAPIがそろっているサービスって、あまりないです。すくなくとも参照系のみ（だいたいはJSONPベース）です。もう少し他にあってもいいと思うんですが、それがなかなかでてこないのは、（本当に必要なの？というビジネス的な判断もあるとは思いますが）そもそも技術的な問題も多くあったからだと思っています。

で、この２つのConnectはそれを克服してるんですが、その問題とは以下の３つです。

1. ブラウザ上でのクロスドメインコミュニケーションをどう実現するか
2. ユーザに同意させる仕組みはどうするか
3. 認証トークンのやり取りはどうするか

1. に関しては、そもそもブラウザのセキュリティ制約が元になっているのですが、これは近年いろいろ研究がなされてきました。JSONPはもっとも普及したブラウザクロスドメイン通信と言えますが、ラージデータの送信（GETのみのためURL長が問題になる）や認証データのやり取りには不向きでした。その後、IFRAMEによるフラグメント識別子による通信方法がこなれてきて、現在様々なサービス／製品で実装されています。GoogleもFacebookもこの方法（あるいはそのvariant）を採用しています。世間的にはやはりまだハックの一種、として見られていることが多いこの方法ですが、どちらにせよ注目しなければならないところではないかと思います。

2. については、プライバシーに関わるようなパブリックでない情報を流通させるためにはかならず必要になるものです。これは、既にアイデンティティ情報が絡んでくるWebサービスの実現においてよく利用されているので、フロー自体は特に難しいものではないかもしれないです。が、3. で上げたトークンのやり取りと絡んで、ブラウザのみで実現するのはいろいろ細かい点で気を使う必要があったります。

3. の認証トークンのやり取りは、OAuthなどでもおなじみですが、ブラウザのみで完結できるように工夫がしてあります。OAuthなどは署名検証等のために秘密鍵をコンシューマが使いますが、Google FriendConnectもFacebook ConnectもどちらもコンシューマがWebブラウザになるので、秘密鍵を持たせることが難しいです。そのため、もう少し軽い方法、例えばGoogleでは、Cookieベースのトークン管理方法を使っています。ただし、3rd Party Cookieではなく、自分のサイトのCookieとしてトークンを保存するため、CSRFの危険性もありません。自分のサイトのCookie漏洩が無いという前提において、コンシューマとして正真性が保証されます。

このように、簡単に見えるAPIの裏で、実はいろいろこむずかしいことをやってたりします。それぞれの技術要素は、普通ならちょこっとコード書いてブログにまとめてハックした気分になって終わりぐらいが関の山の重箱の隅にあるようなものですが、それをまとめあげてサービスとして公開してAPIにまでしてしまいました。たぶんそこにいたるまでにはいろいろめんどくさいことがあったに違いないんです。すでにこなれたものを積み上げていくのがWeb開発だと思ってるとちょっと面食らいます。

でも、その一種変態的な努力があったおかげで、僕らは実った果実を簡単にAPIとして食べることができて、ソーシャルWebやアイデンティティWebサービスがあまねくすべてのWebサイトで低コストに使えるようになっちゃったりする訳です。すごいですね。