« 「Movable Typeでつくる!最強のブログサイト」発売 | メイン | Trackback標準化の件 »

2006年02月24日

TypeKeyとWeb APIの（ちょっとした）落とし穴

[ REST ]

MTブログでお馴染みの、SixApart規格に、TypeKeyという技術的にも興味深いオンライン認証の仕組みがあります。

これ自体は良いもので、近日一般公開予定の（業務系ソフトですが）Webアプリケーションで使ってみようかなーとちょっと頭をかすめたので、実装を考えてみました。

ユーザとしての利点は、色々なところのID＆パスワードを管理する必要なくなる、とか、パスワードを知らせずに様々なサービスで同一のIdentityを利用できるとか…。Webアプリケーション側には、認証情報を保持しないでも良い、というちょっとした利点があります。

TypeKeyの動作として基本的には、

認証画面がWebベースなので、TypeKeyのサイト
https://www.typekey.com/t/typekey/login
へ飛ばして、ログインしてもらって、

認証結果OKだったら、ユーザーのID名と本物か確認するための情報などが_returnで指定したURLにパラメータとしてくっ付いて、リダイレクトされて返ってくる…。

というものだと理解しました。

以上までは良くて、お？いっそ自前の認証捨ててTypeKeyオンリーにしちゃおうか…とまでいったのですが、これにはちょっと問題ありげな事を発見。今開発しているのはいまどきのWebアプリ（w）なので、近い将来的にWebAPIを実装し、クライアントソフトとの連携を考えている訳です。となると、デスクトップ上のクライアントソフトからも認証システムが利用出来ないといけません。今のTypeKeyの仕様だと、用意されたWebページで認証、結果は指定のWebページへ、とデスクトップをすっ飛ばしてくれます。

で、TypeKeyのREST版を希望したいなーと。HTTPのGETでID＆Passのパラメータ付でTypeKeyに接続して、JSONでもXMLでも何でも良いけれど認証結果を返してくれたらOKですから。 Spammer対策には、各クライアントソフトにAppKeyを発行し、疑わしいのはBlackList行き、とか。

もっとも、PC上のクライアントソフト内でIDとパスワードを入力してもらって、それをTypeKeyサーバーに送信している時点で、「サードパーティが生の ID/PW を知ることなく」という第三者の認証システムを利用する利点の一つが損なわれる可能性も無きにしもあらず…というのが難です。しかし、まるっきりサードパーティのWebサイトに自分の素のID＆Passを渡すのと自分のPC環境内のソフトに入力するのはまったく別の次元なので、一緒くたに話すべきではないでしょう。

こう考えると、現状での方法は、PC上のクライアントソフトからや自Webアプリケーションへのログインは自前のID＆Passで認証、それ以外のサードパーティのWebサイトでの利用には、TypeKeyみたいな認証とかを使ってもらうという事になるのでしょうか。なんか違うなぁ…。出来ればTypeKeyオンリーでやれたら楽なのに…ってそれもちょっと違うか。

新たな認証システムのプロトコルを検討されている場合（＊１）（＊２）、このあたりの対応も上手い具合にならないか検討してもらえると嬉しいですが、どうでしょか。

追記：よくよく考えた結論。
１．TypeKeyなどだけに認証を依存したWebアプリケーションは場合によってはイクナイ難があるかも。
２．デスクトップのクライアントは“サードパーティ”扱いではない、という方向でここはひとつ。

投稿者 BlogWrite担当 : 2006年02月24日 21:29

トラックバック

このエントリーのトラックバックURL:
https://www.witha.jp/b/mt-tb-hate-spam.cgi/364

このリストは、次のエントリーを参照しています: TypeKeyとWeb APIの（ちょっとした）落とし穴:

» TypeKey による認証 from 観測気球
TypeKey に限らず、OpenID を採用する場合、Webサービス間の連携上の種々の問題は解決するとして、クライアント側の問題は何も解決されていないんですよ… [続きを読む]

トラックバック時刻: 2006年02月25日 23:22

コメント

拙作のMT プラグイン SpamSubmission では、Bulkfeeds API にアクセスする際に TK でも認証できるようにしてますが、
http://trac.bulknews.net/trac.cgi/browser/SpamSubmission/trunk/SpamSubmission.pl
まさにそういうことをしてます（ユーザ・パスワードをもらって、GETして Location をハック）

MT SpamSubmission の場合はオープンソースなので実害はないと思いますが、そうじゃない場合はユーザ名・パスワードをとられる懸念があるのはおっしゃるとおりですね。

Flickr のAPIはデスクトップアプリでもとられないようによく設計されてますが、その分認証API自体が若干冗長になっちゃっている気がします。
http://www.flickr.com/services/api/auth.spec.html

投稿者 miyagawa : 2006年02月25日 03:20

どもありがとうございます。

「GETして Location をハック」マヂですか（笑）HTMLスクレイピングならぬ、HTTPヘッダースクレイピング…。さっそくソースみて実装を参考にさせていただきます。

（上の記事内容若干書き直したりして変更してます。すみません）

投稿者 BlogWrite担当 : 2006年02月25日 14:52

コメントしてください

TypeKey ID を使って サイン・イン してください。