クロスドメイン通信とアクセスコントロール

とりあえず好きな分野なので、こういう話には飛びつくようにできている

クロスドメインのセキュリティ問題を OAuth で解決する, OAuth のアイデアに kazuho さんからツッコミをいただいた, それ OpenAuth で (ry - まちゅダイアリー(2007-12-07)

これがおそらく可能な実例としてはすでにあり(OAuthじゃないけども)、AOL WebAIM APIJSONPにOpenAuthのセキュリティトークンを乗っけてクロスドメインで機密情報の通信してるし、Google GDataのJavaScript APIGoogle Authのトークンを含めた形でカレンダーにRead/Writeなリクエストをクロスドメインで投げている(iframe越しのトリッキー通信)。いずれもトークンの受け渡しは各サービスとブラウザとの間でダイレクトに行い、サーバ要らずになっているところが特徴。

そもそも、OAuth が使えるということはサーバサイドでマッシュアップが可能だということであり、そのような状況下において、あえてクライアントサイドでマッシュアップを行うメリットがあるのか

Re: クロスドメインのセキュリティ問題を OAuth で解決する - kazuhoのメモ置き場

仕様をよく見てないのだけど、OAuthはサーバが前提でしか実装はあり得ないのかな?トークンを受け取ったコンシューマの証明のために署名が必須だとすると、必然的にそうなるのかもな。Google AuthとかはURLリダイレクトでトークンを受け取った相手が正しいコンシューマであることを前提に許可するモードもあるので、前述のようなことが出来るのだと思う。

あまり関係ないけど、昔FacebookAPIを調べていたときに、フルJavaScriptで書いたクライアントがあるのをみつけて面白いと思ったのだけど、よく見てみたら署名のキーがJavaScriptの中に直書きになっていてずっこけたことがあったのを思い出した。まあそれじゃヤバいよね、という話。