はてなの認証API
（この日記は2月26日に書いています）
はてなの認証APIが Flickr 方式で検討中らしい。
さて、肝心のはてなの認証APIですが、この Flickr の認証APIとほぼ同じことをすれば、とりあえずの要求は満たせるのかなあという雰囲気です。(似たようなことをするのに TypeKey のような仕組みもあります。) … （中略） … なので、はてなの認証APIも Flickr と同様のインタフェースで実装していこうかなと思っています。
TypeKey 仕組みと Flickr の仕組みの違いが分からなくなったので、整理してみる。
TypeKey 認証 API
- TypeKey 認証を使うサービスから TypeKey サーバへリダイレクト
- 利用者はID/パスワードで TypeKey にログイン
- TypeKey サーバからサービスへ認証情報が伝えられる
- サービスは認証情報を検証し、利用者のユーザIDを取得
サービスが受け取る認証情報には「TypeKeyサーバの署名」以外に「タイムスタンプ」も含まれている。 署名を使って利用者が認証情報を改ざんすることを防ぎ、タイムスタンプを使って第三者によるリプレイ攻撃を防いでいる。
Flickr 認証 API
こっちは「Flickr API の認証」で書いた。図だけ再掲。
ユーザIDを含む認証情報を直接渡さずに、 frob とトークンを使っているところが異なる。 以前は、なぜ直接トークンを渡さずに frob を使っているのか分からなかったけど、これもリプレイ攻撃を防ぐためだろう（同じ frob から2回トークンをもらうことはできない）。 トークンの内容はFlickr API: flickr.auth.getTokenを参照。
それぞれの違い
TypeKey と Flickr の認証APIの違いは2つある。
- TypeKey は利用者を介してユーザIDを間接的にサービスに渡す。Flickr は frob （引換券）と引き換えに直接渡す。
- TypeKey はサービスにユーザIDを通知しているだけ。Flickrはトークンを使ってFlickr自体のサービスを使えるようにしている（利用者がサービスに権限を渡している）。
はてなが採用するからという訳じゃないけど、個人的には Flickr 方式が流行するのかなと思っている。
一つ目の理由は、 Flickr 方式のほうがサービス側の実装が軽いこと。 TypeKey 方式だと認証情報やタイムスタンプの検証が必要だけど、 Flickr 方式なら不要。 （ただし、Flickr APIのURLがSSLじゃないので、署名を使うTypeKey方式よりは危険がありそう）
二つ目の理由は、はてなは TypeKey と違って独自のサービスを持っていること。 TypeKey 方式だと、サービス側に利用者の はてなID を通知することしかできないけど、Flickr方式なら、サービス側から はてなのサービスを使わせることができる。
はてなに限らず、Mixi や Google など認証機能を今後提供する可能性があるところは、何らかの独自サービスを持っていると思う。 今後、サービスの API 化（Webサービス？ Web2.0？）が進むことを考えると、認証サービスだけを切り離して提供するよりも、自分のサービスへのアクセスAPI（利用者がサービスに権限を渡すってやつ）もセットで提供するという流れになるんじゃないかなぁ。
OpenIDは？
だとすると気になるのは OpenID の行方。 OpenID認証の仕組み(想像)やOpenID の仕様 動作の概要http://www.goodpic.com/mt/archives2/2005/12/openid_1.htmlやOpenID: Specsを読むと、TypeKey型に近い。 ここギコさんも「OpenIDもYADISもサーバとコンシューマがセットでないと、サーバだけだと駄目」と言っていて、単にOpenIDを使うだけじゃ複数のサービスの情報を統合できない。
最近流行のサービスのAPI化と、OpenIDは相性が悪い気がする。 かといって、Flickr方式だと「分散型IDサービス」は実現できなさそうだけど…。 なんか取りとめがないけど、このへんで。
追記
最初に立ち上げるにしてはかなりオーバースペックなんじゃないかという話もあるなぁ…。