2006年は認証APIの年

| コメント(5) | トラックバック(5)

Webカレンダーの30Boxesが「出す」と宣言していたAPIの一端を公開した。まだイベントの作成と更新が公開されていないが、それが出れば手元のツールと同期するプログラムとか簡単に書けそうだ。

Google、Amazon、eBayで始まったWeb APIの大きな流れは、当初の読み取り専用データのWeb公開(Open Data!)を経て、Flickr APIとその仲間たちやAtom PPのような更新できるAPI(をSPIと呼んだこともあったっけ)へと歩を進めつつある。

更新できるAPIで重要なのは、認証機能だ。30Boxesも、カレンダーにデータを追加することを念頭においているわけだから当然だが、最初から認証機能が用意されている。こんなAPI呼び出しでユーザーの承認を受けることができる。Flickrとその仲間たちも同じような仕組みでユーザーがアプリへ承認を与えることができる。Amazon Web サービスも最近共有秘密による認証をシステムに組み込んだ。

ここで重要なのは、彼らはHTTPのBasic認証メカニズムを使っていないということだ。Basic認証などのHTTPのメカニズムでは、ユーザーはサードパーティのアプリケーションに、そのアプリケーション用ではなく、他のサービスにおける自分のパスワードを教えなければならないからだ。Flickr!は僕が2005年のDevelopers Summitでデモしたときは写真のアップロードにBasic認証を使っていたが、その後現在の仕組みを構築した。Web APIでユーザーのパスワードをアプリケーションに対して入力させるような認証機能は今すぐ仕組みを考え直したほうがいい。パスワードは常にユーザーとサービスとの直接対話でのみやり取りされなければならない。でないとman in the middle認定されてしまう。

と、ここまでの話は実はほとんど先日miyagawaさんとチャットしたときにmiyagawaさんがおっしゃったことだ。miyagawaさんはずっと以前にすでに書いてたし(追記)。日本でも多くのWeb APIが公開されているのは喜ばしいことだけど、どれも認証に本気で取り組んでない感じがする。Open Dataはもう当たり前。あちらのほうでは更新できるWeb APIも当たり前になりつつある。Flickr APIの認証はアプリ作成がちょっと面倒になる場合がある(僕のMTプラグインとか)が、とりあえずそれでもいいし、TypekeyでもOpenIDでも試してみる価値はあるだろう。はてなやmixiは、そのサービスでのアイデンティティがそのまま他のサービス上でも通用することもあるわけで、認証APIがあればサービスの価値が大いに高まると思う。

ところで30BoxesのAPIからのレスポンス。


<?xml version="1.0" encoding="ISO-8859-1"?>
<rsp stat="ok">
<ping>pong>/ping>
<msg>API key for user 14734 was verified.&lt;/msg>
</rsp>

<rsp stat="fail">
<err code="2" msg="Incorrect API key"/>
</rsp>


<rsp> rulez!

トラックバック(5)

トラックバックURL: http://www.luckypines.com/cgi-bin/mt/bt-tm.cgi/806

naoyaのはてなダイアリー - 認証API (2006年2月23日 12:18)

日本でも多くのWeb APIが公開されているのは喜ばしいことだけど、どれも認証に本気で取り組んでない感じがする。Open Dataはもう当たり前。あちらのほうでは更新できるWeb APIも当たり前に... 続きを読む

Kickstart my heart: 2006年は認証APIの年 日本でも多く... 続きを読む

 「2006年は認証APIの年」らしいので、ラボで暖めていた仕様を公開したいと思... 続きを読む

なんだなんだ、どうして日本のメディアは肝心なところを伝えてないんだ? Jeffrey McManus: New Goodies for Developers We call this Browser-Based Authentication. It's a way to enable third-party software developers to get ac... 続きを読む

映画プロデュース会社:取締役の妄想日記 - 米ヤフーが「Mushup」ツールを提供に (2006年3月 9日 15:35)

ウェブ上でマッシュアップが大流行しているのを受けて、Yahooは米国時間3月7日、同社の写真、カレンダー、ショッピング、ブックマークサービスの各 ツールを使って独自のプログラムを... 続きを読む

コメント(5)

http://blog.bulknews.net/mt/archives/001852.html
前に書いた気がしてみてみたら、ここにありました。

> Web APIでユーザーのパスワードをアプリケーションに対して入力させるような認証機能は今すぐ仕組みを考え直したほうがいい。

その API を利用するのが、別のウェブサービスである場合は、おっしゃるとおりだと思います。逆に、API を利用するのが、PC で動作するクライアントアプリケーションである場合は、同じパスワードを使うことに問題はないと思います。

たとえば、フォト蔵の API は、言及している「貼る蔵」を見ても、後者の利用形態を前提にしているんじゃないでしょうか。

>PC で動作するクライアントアプリケーションである場合は、同じパスワードを使うことに問題はないと思います。

配布元およびダウンロードしたファイルの内容を信頼できる、またはソースが公開されていて自分でビルドできるならであって、問題なしと言い切るわけにはいかないと思いますが。変にログとか残ったりしてあとでGoogle Desktopで曝されたりする可能性を考えると。PCで動作するソフトウェアであろうがWebアプリであろうが、パスワード収集機能を持っていないことを信用できなければ同じだと思うのです。僕がパラノイアなだけでしょうか?僕はAtom PPを利用してブログにポストするアプリケーションも使う気になれません。

じゃあiTunesは、puttyはどうなんだっていわれるとツラいところではありますが、そこは信頼できるってことで;)

ご返答ありがとうございます。

> 配布元およびダウンロードしたファイルの内容を信頼できる、またはソースが公開されていて自分でビルドできるならであって、問題なしと言い切るわけにはいかないと思いますが。

PC にインストールされたソフトウェアからは、cookie データベースにアクセスすることやブラウザにキーロガーを仕掛けること等、何から何まで出来てしまいます。
ですので、クライアントアプリケーションにパスワードを教えるか否かでセキュリティ上のリスクが変化することはない、と (理論的には) 言えると思います。

実装上のミスの可能性を含めた危険性については、おっしゃるような観点も含め、いろんな議論が可能だと思います。

いずれにせよ、現行の各サイト毎の API にはいろいろ危険性もあったりするので、ガイドラインなり標準化なりが図られるべきだ、と思います。

> 何から何まで出来てしまいます。
そうでもないです。黙ってそういうことをしようとするアプリケーションを排除することは現行のWindows上でも不可能ではないです。もちろん実際にそういうことを気にかけているソフトウェアと、そういうソフトウェアだけを使おうとするユーザーが少ないということは知っていますが。

APIを使って写真を送り込もうとするクライアントアプリケーションの場合、黙ってパスワードを使うわけではないので、悪意のキーロガーをどうするかという話とはちょっと違いますね。

コメントする

このブログ記事について

このページは、Fumiaki Yoshimatsuが2006年2月23日 09:48に書いたブログ記事です。

ひとつ前のブログ記事は「これもパクリ、模倣、悲しい、コピーキャットですよね?」です。

次のブログ記事は「ALPS LAB BaseにFlickr!上のgeotaggedな写真ページからトラックバックするGreasemonkeyスクリプト」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。