TypeKey による認証

☆

デスクトップ上のクライアントソフトからも認証システムが利用出来ないといけません。今のTypeKeyの仕様だと、用意されたWebページで認証、結果は指定のWebページへ、とデスクトップをすっ飛ばしてくれます。

HepCat Dev and Test: TypeKeyとWeb APIの（ちょっとした）落とし穴

拙作の bookey では、MM/Memo へのブックマーク登録・削除に際して TypeKey 認証経由で MM/Memo にアクセスしています。MM/Memo は自前の認証機能を一切持たず、TypeKey による認証を採用しています。

いずれは bookey の動作原理解説記事とか書こうと思っていたのですが、ここで TypeKey 認証回りについて、どうやっているのかを簡単に書いてしまいます。

処理の流れ的には、以下のような感じ。

1. MM/Memo のトップページにアクセスし、返ってきた Location (リダイレクト先) と Cookie を記憶。
2. 上記 Location (すなわち、TypeKey の認証用の login フォーム)にアクセスし、TypeKey のアカウントとパスワードを引き渡す。
3. 認証に成功すると、Location (MM/Memo のブックマーク管理画面の URL) と Cookie が返ってくるので、これらを記憶。
4. 最初に MM/Memo が返してきた Cookie と、上記の TypePad が返してきた Cookie を合体させて1個の Cookie に統合し、上記 Location (MM/Memo のブックマーク管理画面の URL) にアクセスすることで、MM/Memo のブックマークの管理画面にアクセス可能となる。

つまり、「デスクトップをすっ飛ばしてくれ」るというのは正確ではなく、Cookie と Location の管理はデスクトップ側で行なう必要があります。Web ブラウザはこの辺、ブラウザ側で管理してくれるんですが、自前のデスクトップ(クライアント)では、自分で管理する必要があります。

もっとも、PC上のクライアントソフト内でIDとパスワードを入力してもらって、それをTypeKeyサーバーに送信している時点で、「サードパーティが生の ID/PW を知ることなく」という第三者の認証システムを利用する利点の一つが損なわれる可能性も無きにしもあらず...というのが難です。

HepCat Dev and Test: TypeKeyとWeb APIの（ちょっとした）落とし穴

この辺については、「[OpenID]サーバ側は何とかなるとして、クライアント側はどうするの?」という記事を書きましたので、参照してください。

デスクトップのクライアントは“サードパーティ”扱いではない、という方向でここはひとつ。

HepCat Dev and Test: TypeKeyとWeb APIの（ちょっとした）落とし穴

そうなんですよ。「ここはひとつ、そういうことでお願いします」というしかないのが、クライアント側の現実。 この現実を何とかしたいんですが、今のやり方では原理的にどうにもなりません。Webサービス提供者側と一緒になって新しい仕組みを生み出す必要があるのではないかと思います。

Webサービス提供者が、クライアント側のことにまで頭が回っていない気がするのは、気のせいでしょうか? (と言ってみるテスト)
Webサービス提供者は、Web ブラウザ以外の独自クライアントのことまでは考えていない、というのは十分ありそうだなぁ、と思う今日この頃。