OAuth.ioは，80以上のOAuthプロバイダにインターフェースするAPIであり，サービスである。今回の記事では，共同創設者のMehdi Medjaoui氏とのインタビューを通じて，セキュリティやライセンスなどの詳細，今後の開発計画などについて紹介する。

OAuth.ioは，ユーザ認証やAPI認証のコード記述をシンプルにしようとする試みのひとつだ。開発者は異なるバージョンやプロトコル(1.0, 1.0a, 2.0)を実装した複数のOAuthプロバイダに対応しなくても，以下のスニペットに示すように，ひとつのAPIだけを使ってプログラムすればよい。

$('#fb-connect').click(function() {    OAuth.initialize('YOUR_PUBLIC_KEY');    OAuth.popup('facebook', function(err,res) {        if (err) {            // do something with error            alert(JSON.stringify(err));            return;        }        $('#token').html(res.access_token)                   .parent().show();    });});

サポートするプロバイダはFacebookやTwitter, Google(各種サービス), GitHub, Flickr, LinkedIn, Dropbix など80以上にのぼる。開発チームではこれら以外に，今後サポートするプロバイダの提案を広く求めている。APIには無償あるいは有償のサービスとしてアクセスできる。あるいは，自分のインフラストラクチャでサービスを稼動させることも可能だ。

InfoQはOAuth.ioの共同創設者であるMehdi Medjaoui氏に，APIの詳細と付帯するサービスについて話を聞いた。

InfoQ: OAuth.ioはまだベータ版なのですか？ そうならば，一般に提供されるのはいつ頃になると思いますか？

MM:サービスとしてはすでに，製品アプリケーションに対応できるものになっています。当社の一番大きな製品版ユーザはすでにOAuth.ioを使っていて，ひとつのアプリに12のOAuthを組み込んでいます。

５週間前にサービスをローンチしてから，これまでに1,380を越えるアプリケーションがこのサービスを使用しています。実際に運用しているものも84あります。

それでもまだ，来週提供予定の新機能がたくさん残っています。サービススタックを数十万，あるいは数百万のユーザアプリケーションで評価してもらわなくてはなりませんから，当面はベータの段階を継続するつもりです。

InfoQ: OAuth.ioを使って認証を行うユーザは，Amazonで稼動しているoauthdデーモンを経由すると理解していますが，それで正しいでしょうか？ 処理プロセス全般について，簡単に説明して頂けますか？

MM:OAuth.ioは現在，80以上のOAuthプロバイダにひとつのAPIで対応しています。実際のOAuth.ioは，私たちが開発しているオープンソースのOAuthデーモンであるoauthdのクラウドホスト版なのです。OAuth.ioサービスは，Amazon EC2で稼働しています。さまざまなOAuthプロバイダを統一した方法で操作できる，シンプルで使いやすいWebインターフェースを開発者に提供します。

ではOAuth.ioは何をするのか，ということですが。

JavaScriptで記述されたユーザアプリケーションはOAuth.popupか，あるいはOAuth.redirectをコールします。それがOAuth.ioに対して，接続先のプロバイダを指定したリクエストを行ないます。それからOAuth.ioが，プロバイダの認証フォームをポップアップあるいはリダイレクトするための情報を送信するのです。認証が完了すると，プロバイダはoauth.ioにリダイレクトします。oauth.ioはトークンを要求して，それをOAuth.popupあるいはOAuth.callbackのJavaScriptコールバックに返信します。

サーバ側のフローでは，ユーザアプリケーションは単に，サーバに(Ajax要求を通じて)送信されたコードを受信します。その後でサーバがoauth.ioに，秘密キーを添えてトークンのコード交換を要求するのです。

InfoQ: 現時点では，ユーザのプライベートAPIキーをストアするという，セキュリティ上の大きな問題があります。これについては，どのような予定がありますか？

MM:セキュリティの問題は，開発者のOAuthインテグレーションを解決するという私たちのミッションの中でも，もっともプライオリティの高いものです。まずはセキュリティ，それからパフォーマンスや開発者フレンドリなエクスペリエンス，という順です。

OAuth.ioは，アプリケーションにOAuthを提供するバックエンド・アズ・ア・サービス(BaaS)ですので，他のBaaSと同じように，アプリケーションのAPIキーが必要です。OAuth.ioではセキュリティを次のように確保しています：

- oauth.ioとユーザ間の通信をセキュアにするため，すべてEV SSLで暗号化しています。

- コードは使い捨てで有効期間も短いので，第三者が再利用することはできません。

- 有効なドメイン/URLは詳細レベルによって違います - 単一のスキーマ/ドメイン/ポート/パスに制限することも可能で，アクセストークンを漏えいさせるようなリダイレクションの詐称が不可能になります。

- サーバ側での認証時に "state" パラメータを必須とすることで，CSRFエクスプロイトを回避しています。

- クライアント側/サーバ側 (トークン/コード) は要求ではなく，アプリケーションの設定によって判断されます。これによってトークンの取得は，要求パラメータ変更のように簡単なものではなくなります。

- 最悪の攻撃時においてもプライバシを確保するため，一切のaccess_tokenを保管していません。

- 先日のFacebookのハックを想定して，URLフラグメントのリーク(リファラからのaccess_token取得)を回避しています。

- CSRF/XSSの潜在的なセキュリティエクスプロイトを多数調査して，それらのテストすべてにパスするようにAngular.jsを修正しました。

- 全体としてWebサイトはAPIベース/API駆動ですので，セキュリティを比較的簡単に管理することができます。

APIキーをホストする必要のある処理がどこにあるのかをユーザに完全に透過的にするため，コードはオープンソースとしています。oauthdデーモンのオープンソース版をインストールすることも可能です。ソースはGithubhttps://github.com/oauth-io/oauthdに公開されています。

InfoQ: 自分自身ですべてをコントロールするために，自らのサーバ上でoauthdを実行することを望んだならば，あなた方からoauthdをライセンスしてもらえるのですね？その場合のライセンス条件について，何か触れておくべきことはありますか？

MM:はい，oauthdは "サーバテクノロジ用のGPLライセンス"であるAffero GPLライセンスで提供されるオープンソースで，例えばMongoDBなどと同じです。http://blog.mongodb.org/post/103832439/the-agpl

このライセンスはとても新しいものなので，なぜAGPLではcopyleftがプロジェクト全体にではなく，oauthdの変更に対してのみ有効であるか，理由を説明する必要がありそうですね。

oauthdはデーモンとして動作する独立したアプリケーションです。インストール後にoauthdを修正した場合は，同じオープンソースライセンスでコミュニティに再配布しなければなりません。しかし他の古いGPLライセンスのように，プロジェクト全体のコードを配布する必要はなくなっています。

つまり，

- すべてのオープンソースプロジェクトは，oauthdをアプリやプロジェクトで使用することができます。

- oauthdを独立したサーバとして使用するクローズドソースプロジェクトは，(プロジェクト全体ではなく)oauthdの変更部分だけをコミュニティに再配布する必要があります。

oauthdの変更部分やリンクされるコードを，非公開で自分たちのサーバに組み入れたいと考える企業に対しては，コマーシャルライセンスが提供されています。ライセンスの価格は，必要なサポートサービスの深さによって異なります。

AGPLについて今一度，説明しておきましょう：

私たちがAGPLを採用した理由は，oauthdでcopyleftのコンセプトを維持するためです。従来のGPLでは，cophyleftはソフトウェアの配布に関連したコンセプトでした。しかし今日，ソフトウェアを配布することは少なくなりました - クラウド上で動作が完了するようになったのです。AGPLでは，ネットワーク上でソフトウェアを利用する場合にもcopyleftが有効であると宣言しています。それによってGPLの"穴埋め"をしているのです。それ以外に関しては，GPL v3と実質的に同じライセンスです。

InfoQ: ロードマップはどうなっていますか。JavaScript以外の言語をサポートする計画はあるのでしょうか？

MM:ええ，もちろん。 次のステップとしてはモバイルを考えています。iOSやAndroid，BlackBerry用のSDKなどを使用します。他の言語よりもモバイルを優先してほしい，というEメールをたくさん受け取っています。これらすべてのSDKを９月初旬にローンチできればと思います。

それから他のPythonやRuby, PHP, .NET, Java SDKなども，今年末までに開発したいですね。