facebook)Webのユーザ認証とSSOに関する技術メモです。AuthSub、OpenSocial、OpenIDなど。ユーザ認証はパスワード認証に限定します。いわゆるフォーム認証を仮定します。モデル的にはパスワード認証やフォーム認証に限定する必要はありませんが、Webの世界では現実的にこのスタイルに限定されているのでこうします。この限定をせずに表現を抽象化すると、ユーザIDの代わりに認証子、パスワードの代わりに秘密情報とかになって百害あって一利無しだからです。シナリオは、新しいWebアプリを作った開発者がいるところから始めます。開発者AさんがWebアプリを作りました。そのWebアプリはユーザにログインしてもらう必要があります。目を転じるとWeb上には既に巨大なユーザアカウントを抱えたWebアプリが存在しています。一般的な定義とは異なりますが、巨大なユーザアカウントを抱えるWebアプリをここではSNSと呼ぶことにします。この定義に従うと、mixiみたいなものだけではなく、blogサービスでもAmazonでもGoogleカレンダーでもSNSです。用語の使い方が気持ち悪ければ、以下、SNSを単に新しく定義した記号と思ってください。登場人物が揃ったので列挙します。開発者Aさん開発者Aさんの作ったWebアプリX(巨大なユーザアカウントを抱える)SNSSNSのエンドユーザたちさて、開発者Aさんは、新しいWebアプリXのユーザを獲得したいわけですが、自前でユーザ認証を実装すると次のような苦労があります。セキュリティ的に穴の無いユーザ認証システムを作るのは色々と面倒ユーザのパスワードを保持してしまうと気をつかうユーザ管理はそもそも面倒ゼロからユーザを集めるのも大変SNSにユーザ認証を任せて、認証済みのユーザに自分のWebアプリを使わせると、上の問題がすべて解決します。エンドユーザから見ても、わざわざ新しいサービスを試すたびにユーザ登録をする手間が省けます。SNSはユーザ囲い込みに使えます。それぞれの思惑が合致します。On)です(SSOを実現する形式で分類すれば、これから説明するSSOはリバースプロクシ型SSOの一種です)。この時、技術的に満たすべき要件は次のようになります。絶対ルールエンドユーザは、SNSとだけパスワードをやりとりしますエンドユーザは_決して_、WebアプリXとパスワードのやりとりはしませんこのルール下で、WebアプリXは、エンドユーザがSNSによって認証済みかどうかを知りたいとします。これを満たす技術は今に始まったわけではなく、クラシックなKerberosと基本的に同じモデルで実現できます。APIなども登場しています。派生形を無視して、通信フローを単純化すると次のようなやりとりをします。余談ながら、この手の絵でHTTPのリダイレクトのレスポンスを省略して、そのまま別サイトに飛ばす絵がありますが、個人的に好きになれません。以下の絵はリダイレクトの省略はしていません。実際にはセキュリティ上、考慮すべき点が多々あります。replay攻撃への対策として時刻情報を混ぜたり、また一般的にはWebアプリXとSNSの間であらかじめ秘密情報を共有しておきます。APIとして公開している前提です。API」という用語をかなり広義に使っています。SNSが上のような仕組みを用意してくれていれば、開発者Aは、自前でユーザ認証を実装する代わりに、上のようなプロセスを実装することになります。ほとんどの場合、API(プログラミング言語で呼び出すAPI)が提供されていて、上のような通信フローを隠蔽しています。ここまでで、開発者Aは面倒なユーザ管理から開放されました。WebアプリX内では、SNSが割り当てた(たいていは整数値の)ユーザIDでエンドユーザを識別すればよいだけです。Calendar、facebook、OpenSocial等では更にふたつの仕掛けがあります。Calendarやfacebookに相当すると思ってください。仕掛けのひとつ目は、上図の認証フロー後、WebアプリXがSNSに対して、エンドユーザの権限のまま振る舞う点です。通常、エンドユーザがSNSにログインしてからブラウザでやるような作業を、WebアプリXがそのユーザの権限で行ってしまいます。WebアプリXがSNSからGETでデータを引っ張ってきたり、POSTでデータを書き換えたりできます。これらをエンドユーザの権限で行います。