«前の日記(2006-02-24 (金)) 最新 次の日記(2006-02-26 (日))»  

まちゅダイアリー


2006-02-25 (土)

はてなの認証API

(この日記は2月26日に書いています)

はてなの認証APIが Flickr 方式で検討中らしい。

さて、肝心のはてなの認証APIですが、この Flickr の認証APIとほぼ同じことをすれば、とりあえずの要求は満たせるのかなあという雰囲気です。(似たようなことをするのに TypeKey のような仕組みもあります。) … (中略) … なので、はてなの認証APIも Flickr と同様のインタフェースで実装していこうかなと思っています。

TypeKey 仕組みと Flickr の仕組みの違いが分からなくなったので、整理してみる。

TypeKey 認証 API

TypeKey Authentication

  1. TypeKey 認証を使うサービスから TypeKey サーバへリダイレクト
  2. 利用者はID/パスワードで TypeKey にログイン
  3. TypeKey サーバからサービスへ認証情報が伝えられる
  4. サービスは認証情報を検証し、利用者のユーザIDを取得

サービスが受け取る認証情報には「TypeKeyサーバの署名」以外に「タイムスタンプ」も含まれている。 署名を使って利用者が認証情報を改ざんすることを防ぎ、タイムスタンプを使って第三者によるリプレイ攻撃を防いでいる。

Flickr 認証 API

こっちは「Flickr API の認証」で書いた。図だけ再掲。

flickr (2)

ユーザ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.htmlOpenID: Specsを読むと、TypeKey型に近い。 ここギコさんも「OpenIDもYADISもサーバとコンシューマがセットでないと、サーバだけだと駄目」と言っていて、単にOpenIDを使うだけじゃ複数のサービスの情報を統合できない。

最近流行のサービスのAPI化と、OpenIDは相性が悪い気がする。 かといって、Flickr方式だと「分散型IDサービス」は実現できなさそうだけど…。 なんか取りとめがないけど、このへんで。

追記

最初に立ち上げるにしてはかなりオーバースペックなんじゃないかという話もあるなぁ…。