トップ «前の日記(2011-07-18 (月)) 最新 次の日記(2011-08-01 (月))»  

まちゅダイアリー


2011-07-22 (金)

新しい認証方式 BrowserID を分かりやすく解説してみる

BrowserID という認証方式がはてなブックマークやTwitterで話題になっていたけど、話題元のニュース記事を見てもどんな仕組みか全然分からない。 なので、 BrowserID の何が新しいのか、ちょっと調べてみた。

Firefox、ログインの常識を変える「BrowserID」を発表 | エンタープライズ | マイコミジャーナル

  • サーバ側の実装もクライアント側の実装もOSSとして公開されている。
  • クライアント側の実装はJavaScriptとHTMLのみで行われており、クロスブラウザで動作する。
  • このログインサービスを利用するためのクライアント側の開発は数行追加する程度で済む。
  • 通信には「Verified Email Protocol」と呼ばれる安全なプロトコルを採用している。

クライアント側でも実装が必要なことが分かった。でも、本質的にクライアントだけで認証が完結することはありえないので、サーバ側の実装も必要なはず。 サーバ側の実装については説明がないので、どのような仕組みか全く分からない。 ブックマークコメントでも「OpenIDと何が違うの?」というコメントがあったので、まずは OpenID, OAuth, BrowserID の違いを図にしてみた。

なお、以降の図では比較のために細かなシーケンスを省略して、代表的な部分だけを載せている。

OpenID

OpenID では、 URL をユーザのIDとして使う。 例えば、 flickr がOP (OpenID Provider) であれば僕のユーザIDは http://www.flickr.com/photos/machu/ となる。 ユーザは OP へログインし、ユーザを経由して OP から RP へと認証結果が送られる。 RP は認証結果が正しいかどうか(ユーザが不正に認証結果を改ざんしていないか)を、事前に OP との間で交換していた鍵を使って検証する。

OpenID Authentication

OAuth

WebAPI のアクセス制御に使える OAuth という仕様でも書いたように、 OAuth はもともと Web サイト上の個人のリソースへのアクセスを第三者へ許可するための仕様。Twitter の API への認可で使われているのが、一番有名だろう。 本来は認可のための仕様だけど、認可するためには認証も必要なので、「Twitterでログイン」などによく使われている。 ユーザはClient (OpenIDでいうRP) に対してアクセス権限を与え、ClientはSPからユーザ情報(ID, 名前, メールアドレスなど)を取得する。

OAuth Authentication

BrowserID

BrowserID は現時点ではコンセプトとデモが示されているだけで仕様書がないので、How BrowserID Worksのシーケンスを参考にした。 BrowserID も OpenID や OAuth と同じように、第三者 (Trusted Third Party) を使った認証方式。 BrowserID では、メールアドレスをユーザIDとして用いる。 ユーザはId Authority(GMailなどのWebメールを想定している)にログインし、Id Authorityから証明書を受け取る。 ユーザはRPへ証明書を提示し、RPは受け取った証明書に書かれているメールアドレスを取得する。 もちろん、RPは証明書が偽造されていないことを、(Id Authorityの公開鍵を使って)検証する。

BrowserID (full support)

ここでは分かりやすく「証明書」と書いたけど、技術的には公開鍵暗号(のデジタル署名の技術)を利用している。 SSLのクライアント証明書を知っているのであれば、それと似たような仕組みと思えばいい。

この説明だけじゃ、OpenIDやOAuthと何が違うのかが良く分からないかもしれない。 違いについてはもうちょっと後で説明する。

SSL クライアント認証

話の流れ上、SSLクライアント証明書を使ったフローも載せておく。 ユーザはあらかじめ、CA (Certificate Authority) から証明書を発行してもらう。 このときの本人確認の方法は、発行する証明書の重要性によって異なる。 例えば、オンラインで電子メールの確認だけで発行される証明書もあるし、e-Taxで使う公的個人認証サービスのように市区町村の窓口で発行される証明書もある。 証明書もファイル形式だったり、ICカードに格納したりと様々。

ユーザがサーバにログインするときは、この証明書を提示して自身を証明する。 (技術的には正しくない説明なので、詳しくは新版暗号技術入門 秘密の国のアリス(結城 浩)などを参照)

SSL/TSL Client Authentication

BrowserIDは何が新しいのか

ここまでの説明だと、なんとなくOpenIDやOAuthと同じように見える。 では、BrowserIDは何が新しいのか。

第三者 (Trusted Third Party) を使った認証方式は、ざっくり言うと2つのステップに分けられる。 (TTPはOpenIDのOP, OAuthのSP, BrowserIDのId Authority, PKIでのCAを指す)

  1. 第三者 (TTP) がユーザを認証する
  2. ユーザの認証結果をサーバへ流通させる

「サーバに流通」とは、例えばTwitterがRPのサーバに対して、この人は @machu だと紹介してるようなもの。 これまでのWebでの認証方式では、ユーザがRPへログインするたびに紹介してもらう必要があった。 なぜなら、ユーザ側(Webブラウザ)には、紹介状を保存する仕組みがなかったから。

前置きが長くなったけど、BrowserIDがOpenIDと決定的に異なるのは、この紹介状(証明書)をWebブラウザに保存する仕組みを作ろうとしていること。 さっきのフローをよく見ると、ユーザを経由して認証情報を渡す矢印に違いがある。 OpenIDとOAuthでは矢印が繋がっているのに対して、BrowserIDとSSLクライアント認証ではId AuthorityやCAからユーザへの矢印と、ユーザからRP、サーバへの矢印が分かれている。ここが一番の違い。

BrowserID (full support)

BrowserID側の主張

では、紹介状(証明書)をWebブラウザに保存することがなぜ必要なのか。 BrowserIDの紹介:より良いサインインの手段 « Mozilla Developer Street (modest)には、以下のように書かれている。

他の選択肢として Facebook や Twitter、Google といった大手の ID プロバイダにログインと認証の管理を任せることもできますが、これらのプロダクトは、ロックインや信頼性の問題、データのプライバシーの懸念も招くものでもあります。

OpenIDやOAuthでは原理上、ユーザがどのサイトにログインしたかを、 OP (SP) が知ることができる。 BrowserID 側はこれを「プライバシーの懸念」と主張していて、解決策として証明書をWebブラウザに保存する仕組みを提案している。 なお、あくまでBrowserID側の主張であることに注意。何をプライバシーの懸念と見なすかは複雑な問題なので、ここでは深入りしない。

実装方法とbrowserid.orgによる暫定解

Webブラウザに証明書を保存する仕組みはJavaScriptのAPIとして定義されている。 これまたHow BrowserID Worksより。

API役割
navigator.id.genKeyPair()新しい鍵ペアを生成する
navigator.id.registerVerifiedEmail()鍵ペアとメールアドレスの対(証明書)をWebブラウザに登録する
navigator.id.getVerifiedEmail()Webブラウザに登録されている証明書を取り出す

つまり、BrowserIDの世界が実現するためには、以下がクリアされる必要がある。

  1. WebブラウザにこれらのAPIが実装される
  2. Webメールの提供者(GMailなど)がId Authorityとしての機能を提供する

もちろん、現時点ではこのようなAPIは実装されていない。 なのに、browserid.orgでは開発者向けのデモサイトを用意している。 このデモサイトは、以下のように browserid.org というプロキシを使った暫定解になっている。

  • browserid.org はWebメールサービス提供者の代わりにId Authorityの役割を提供する
  • browserid.org は Webブラウザにて registerVerifiedEmail(), getVerifiedEmail() 関数を提供する

以下のスクリプトの中で、registerVerifiedEmail() と getVerifiedEmail() が定義されている。

<script src="https://browserid.org/include.js" type="text/javascript"></script>

証明書の格納は browserid.org ドメインへの Web Local Storage を使って実装されている。 そのため、デモサイトで myfavoritebeer.org へログインする時に、毎回 browserid.org ドメインへリダイレクトしている。 つまり、暫定解での BrowserID は完全に browserid.org に依存した構成になっている。

BrowserID (browserid.org)

BrowserIDが目指す理想を目に見える形にするための暫定解なんだろうけど、 browserid.org という特定のサイトに依存しているため、元々の理想が見えにくくなっている。

他の選択肢として Facebook や Twitter、Google といった大手の ID プロバイダにログインと認証の管理を任せることもできますが、これらのプロダクトは、ロックインや信頼性の問題、データのプライバシーの懸念も招くものでもあります。

デモサイトだけみると、 Facebook, Twitter, Googleが browserid.org に変わっただけで、何が違うの?と思ってしまう。 それに、「数行のコードを書くだけで認証を実現」というのも、サーバ側の検証をbrowserid.orgに任せる方式だったりと、セキュリティ&プライバシーよりも利便性・分かりやすさを優先している印象を受ける。

BrowserIDへの批判

理想と現実のデモサイトに乖離があることもあって、BrowserIDへの批判も出ている。 ここではリンクだけを提示しておく。

まとめ

分かりやすく書こうと思ったけど、結局長くなってしまった…。 BrowserIDのポイントは以下3点だと考えている。

  • メールアドレスをグローバルなIDとして使うことの是非
  • ユーザのログイン先がTTPに情報が集まることを、どこまでプライバシーの懸念と見なすか
  • BrowserIDが目指す理想とbrowserid.orgによる暫定解の乖離

まだコンセプト段階のため、実用しようとするとまだまだ考えることは多そう(証明書ストアへのセキュリティはどう担保するかなど)だけど、考え方は面白い。

参考リンク

本日のツッコミ(全4件) [ツッコミを入れる]
心は萌え (2011-07-25 (月) 19:03)

証明書の取り消しをリアルタイムに問い合わせないと、いけないはずなので、どのみち、いつ証明書が使われたかはバレてしまうのではないでしょうか?<br>逆に、証明書の取り消しを即時行えないほうが、プライバシー的には問題だと感じました。

まちゅ (2011-07-25 (月) 21:36)

確かに取り消し対策はちゃんと考えないとダメですね。<br>もしくは、Webメール前提であれば証明書の有効期限を極端に短くするとかでしょうか。

初心者 (2011-07-26 (火) 09:29)

「OpenIDやOAuthでは原理上、ユーザがどのサイトにログインしたかを、 OP (SP) が知ることができる。」<br>については、BrowserIDでもシーケンスの4でわかるのではないでしょうか。<br>リダイレクトするURIよりは粒度は荒くなりますが。

初心者 (2011-07-26 (火) 09:32)

あぁ。。すみません。<br>シーケンス2と4が連動していないので、ユーザを特定することができないのですね。。。<br>初心者丸だしのコメントで汚してしまって申し訳ありません。<br>よろしければ上のコメントも削除してください。。。。