JavaScript による OAuth 認証とそのセキュリティ2010-08-16

TwitMgr (閉鎖済) のバージョンアップを行いました。
OAuth 対応がメインではありますが、地味に日本語の表現を修正して、初見でもやれることが分かりやすくなっているかと思います。

BASIC 認証から、OAuth 認証へ変更するにあたっては、どうしても使い勝手が低下してしまうのは避けようがないところで、そこが残念ではあります。
どうせ OAuth 認証にするならいっそ、サーバサイドをしっかり作り込めばユーザビリティの低下を最小限に抑えられるはずなのですが、元々 JavaScript だけで作られていたものを移植するとなると、ほぼ作り直しになってしまうので、現状で出来る唯一の手段としてはこんなところです。

というのは前置きでして、JavaScript による OAuth 認証について突っ込んで考えたので、以下本論。

TwitterAPI2.js (というか実質は、TwitAPI.js) を使った OAuth 認証では、js ファイルを読み込むたびに、毎回必ず OAuth 認証の確認画面を表示する仕様としています。
プロキシサーバで OAuth 認証を行う構成なので、やろうと思えば、初回アクセス時のみ確認を取る、という事も可能なのですが、そのようにしていないのにはセキュリティ上の理由があります。

TwitAPI.js では、同ライブラリで公式のプロキシサーバを用意していて、公式プロキシサーバに対して許可した OAuth 認証については、その情報がプロキシサーバ側に残ります。
なので、毎回、認証画面を表示するようにしないと、あるアプリ A に対して許可したつもりの OAuth 認証が、他のアプリ B からも簡単に流用できてしまうのです。
毎回許可を得る形であれば、他のアプリ B から無言でいきなり OAuth 認証が悪用されることは避けられます。

クッキーに保存した情報を組み合わせて認証することで、あるアプリ A (ドメイン a) に対して許可した認証を別のアプリ B (ドメイン b) から利用させないようにする実装も検討しましたが、TwitAPI.js の立場から、任意のアプリ A が信用できない以上、アプリ A に XSS があれば同じ事になってしまうので、クッキーを使った実装も見送りました。

Twitter API を JavaScript から利用可能にするための実装は、TwitAPI.js 以外にも見かけますが、そういったセキュリティ上の対応はどうなっているんでしょうかね？調べたことはないですが興味はあります。

JavaScript の場合、そのソースが、設定情報も含めて全て公開されてしまうので、OAuth 認証において本来であれば秘匿すべき情報 (Consumer secret とか最たるもの) を隠すのは困難です。というか、原理的に不可能です。

TwitAPI.js では、プロキシサーバを経由することで、TwitAPI.js 専用のハッシュを発行して Consumer secret を秘匿していますが、専用ハッシュが漏れた場合に備え、前述の「毎回認証画面」でセキュリティを保っているという形です。(専用ハッシュが漏れなくても、TwitAPI.js では共通プロキシを使用している時点で必須です。)
JavaScript で簡単に OAuth を利用したいという要求と、セキュリティを担保するという要求は相反する点が多く、現状で考え得る落としどころはそこであろうという判断です。

JavaScript による OAuth 認証で、初回のみ認証画面が表示されるような実装のアプリがあった場合、原理的にその OAuth 認証は、他のアプリから悪用されうるのではないかと考えています。
この点、もっとスマートに解決するやり方があれば、是非、識者の意見を伺いたいです。