OpenID のセキュリティ

河本孝之(KAWAMOTO Takayuki)

Contact: takayuki.kawamoto@markupdancing.net

ORCID iD iconORCID, Google Scholar, PhilPapers.

First appeared: 2008-03-29 00:00,
Modified: [BLANK],
Last modified: 2011-09-24 20:48.

過去に運営していた architectures.jp というサイトで公開した文章を再掲載しておきます。元々は (1) から (4) の連載記事だったのですが、今回の再掲載にあたって合わせました。なお、この文章を読んですぐに気づく方もおられると思いますが、OpenID 界隈の或る人物とお互いのサイトでつまらない皮肉を書き合うという馬鹿げた事態に発展したため、「こちらの」つまらない皮肉や批判は取り除きました。

この時期にこのような文章を再掲載すると無用な誤解を生じることも承知していますが、僕は OpenID が色々なサービスでサポートを打ち切られているとか、いまや国内では mixi の開発者囲い込みにしか使われていないといった嘲笑の類を一つ加えるために再掲載するわけではありません。僕にとって OpenID なりオンライン・アイデンティティという話題の重要性や個々の論点に関する評価ないし結論は、37signals や StackExchange のようなどうでもいい瑣末なベンチャーや JanRain 社の動静くらいで変わるわけがありません。

それから、この文章について誤解が多いので最初に明言しておきますが、以下の文章は「OpenID をDISる」ためのものではないということです。僕はオンライン認証なりデジタル・アイデンティティを考えるためのきっかけとして、OpenID をはじめとする認証スキームが数多く出てきていることは積極的に支持しますし、エンドユーザが自分自身で信頼しうる認証プロバイダを選び管理できるというしくみを支持します。したがって、以下の文章で疑問を呈している多くの論点は、「現状の仕様」であるとか、「規格策定や検討方法にかんする現状の体制」について指摘しています。

その1

さきごろ Yahoo! やマイクロソフトが OpenID をサポートすると表明しています。OpenID に限らず、昨年のいまごろは認証の仕組みについて調べていたのですが、セキュリティやサーバ管理を扱ったブログなどを見ていると、それほどセキュアではないという指摘があります。そこで、いま現在どうなっているのか、改めて調べてみました。

パスワード認証について

OpenID のセキュリティについて検討する前に、まず OpenID が登場する前から使われている認証方法を、幾つか簡単に説明します(ここで確実に押さえておきたいのは、OpenID がそれらの認証方法よりも「進んでいる」とか「安全な認証方法である」とは言えないということです)。それでは、最初は殆どの方が毎日のように利用している、標準的なパスワード認証を見てみましょう。

Password Authentication

或るサービスを利用したいユーザが、そのサービスを提供するサイトへアクセスします(A)。そのサイトがサービスを提供するにあたってユーザ認証を導入している場合、サイトを運用するサーバは図にあるようなベーシック認証のウィンドウをユーザーエージェント(多くの場合はブラウザ)に開かせるよう促したり、あるいは同様の項目を入力させるページへ画面を遷移したりします。ユーザは指示された「ログイン情報」あるいは「アカウント情報」を入力し、ユーザーエージェントがサーバへ情報を送信します(B)。ユーザからのアカウント情報を受け取ったサーバは、既に登録してあるデータと突き合わせて(C)、合致すれば合致したなりの処理をしてレスポンスをユーザ側へ返します(D)。ユーザから求められている処理がサイトへのログインであればログイン後の画面をユーザへ表示しますし、どこかのディレクトリへ入ることであればディレクトリ内のファイルやディレクトリを一覧表示します(E)。パスワード認証の特徴は、もちろん何らかのサービスを提供するにあたってアカウント情報が一致しなくてはならないということです。しかし逆に言えばそれだけでサービスを提供するわけですから、アカウント情報が一致しさえすれば、そのアカウント情報を入力した人が誰であるかは問いません(たとえホストの IP アドレスも照合していようと、このレベルの認証方式には、その操作が本当にサービスを提供すべきユーザによるものかどうかの判定はできません)。したがって、情報セキュリティの本にはたいていパスワードの管理をしっかりやろうと書かれているわけです。ID やパスワードをどれだけ多くの桁数で設定しようと、他人に漏洩してしまえば元も子もありません。また、自分自身がパスワードを紛失したり忘れてしまった場合も、「いや、俺だから入れてよ」などと言って通用するサーバはありません。

Password registration

パスワードを使ったユーザ認証は、個々のサービスでそれぞれ別の仕組みを利用しており、またユーザが入力したアカウント情報と照らし合わせるデータも、個々のサービスによって異なります。「異なる」というのは、必ずしも異なる文字列である必要はありませんが、ふつうは物理的に別のデータ(別のデータベースサーバに記録されているデータであることが多い)であるという意味です。したがって A というサービスを利用するには、A というサービスに特化したアカウント情報を登録しなくてはならず、B という別のサービスを利用するにも B というサービスに特化したアカウント情報を登録しなくてはなりません。たとえ同じ内容のアカウント情報を毎度毎度入力し登録しているにせよ、それらはサービスごとに登録しなくてはならないわけです。そうなっている理由は、サービスが別々の会社によって提供されており、別々のサーバにデータが置かれていてデータのやりとりが単にないからというだけではありません。これに加え、「データのやりとりが技術的に可能であってもやってはならない」という法的な制約があるからです。つまり、パスワードと共に登録されている幾つかの情報には、認証に使うわけではありませんが、住所や実名などの個人情報が含まれているかもしれないからです。ですから、たとえ A と B を同一の会社が運営していても、A で登録されたアカウント情報をそのまま B でも利用できる状態にすること(つまり両サービスのアカウント情報を一つのテーブルで区別せずに運用するといったこと)は、個人情報保護法の観点に照らすと許されることではありません。

また、個人情報保護法は「個人情報取扱事業者」となる団体や企業(プライバシーマーク制度で認定を受けているかどうかにかかわりなく、5,000 件以上の個人情報を扱ったら個人情報保護法の適用・制約を受けます)だけを対象としていますが、倫理的な範囲にまで拡大すれば、EC サイトを運営している個人にもそれなりの情報セキュリティマネジメントが求められるべきであろうと言えます。しばしば顧客のメールアドレスを幾つ集めたかを自慢する EC ショップのオーナーがいますが(EC ショップを運営する目的はそんなことではないはずです)、そういった方は顧客の情報をどのように管理・運用しているのでしょうか。

Many registrations

こういった次第で、サービスごとにパスワードを含むアカウント情報を登録しなくてはなりません。アカウント情報を登録するフォームを思い起こしてみてください。名前にはじまって住所や生年月日、更には既婚か独身かも聞かれたり、個人情報保護法で言う「特定の機微な(センシティブな)」 情報すれすれのところまで入力させる場合もあります。毎回こんなに入力しなくてはならないなんて、面倒にも程があると思いたくもなります。また、EC サイトを運営していて決裁代行会社との契約を結んでいる方であれば、あの厳めしい与信請求フォームをお客さんに使わせるのはどうかと思うかもしれません(もちろん API を操れる担当者を雇うだけの投資ができれば、ユーザビリティの問題は或る程度まで解決できるでしょう)。

シングル・サインオン

これまでのようなパスワード認証だけでは、サイトやサービスごとにアカウント情報を登録しなくてはならず、アカウント情報を漏洩させたくないと思えば、ユーザ側では長くて複雑なパスワードを頻繁に変更しなければならないと言われています。使い勝手を考えれば非常に煩雑な作業をたびたび繰り返さなければなりません。そこで、「シングル・サインオン」と呼ばれる認証システムが提案されました。

Single Sign-On

シングル・サインオンを導入すると、ユーザは認証サーバにアカウント情報を一回だけ登録し、そのアカウント情報でログインすれば(A)、認証サーバがそれぞれシングル・サインオンに対応するサーバ(サービス)を利用できるように、許可してくれます(C)。シングル・サインオンに対応していれば、サービスを運営するサーバは Windows でも Linux でも MacServer でも構いません。利用したいサービスが複数あっても、認証サーバでのアカウント認証を経て正当な登録ユーザとして認められれば、どのサービスであっても一つのアカウント情報で利用できます(D)。ということで、アカウントの登録も一回で済みますし、ウェブサーバへの自動ログイン機能も提供されていれば、複数のサービス間をログインし直すことなく渡り歩けることになります。このようなシングル・サインオンを導入しているサービスで最もよく知られているのは、マイクロソフトの Windows Live ID でしょう。 もちろん、Windows Live ID は殆どマイクロソフトの提供している複数のサービスを利用できるところまでなので、異なるサーバに同じアカウント情報が使えると言っても、企業どうしの連携がなければ Windows Live ID でサインインしても iGoogle や My Yahoo! が使えるようにはなりません。

OpenID

そこで登場したのが OpenID です。OpenID の概略を理解するには、「識別子(identifier)」、「プロバイダ(IdP: identity provider)」、そして「認証依存サービス(RP: relying party)」または「コンシューマ(consumer)」という三つの要素を知っておくとよいでしょう。

OpenID

まず (A) では、OpenID を取得するフローを説明しています。プロバイダと呼ばれる、OpenID の認証情報をストックするプロバイダ(または “IdP (Identity Provider)” とも言います)へ、氏名や住所やメールアドレスあるいは電話番号などの各種情報を登録し、OpenID を発行してもらいます。ここでは試しに、VeriSign のサービス (Personal Identity Provider) を利用したとしましょう。OpenID の登録では、従来のユーザ登録と同じように氏名や生年月日など、ユーザを識別するための色々な情報を登録します。そしてもちろん、この Personal Identity Provider サービスへのログイン情報としてパスワードも登録するのです。登録が完了すれば、ドメインの書式になっている文字列が発行されます。これが OpenID となります。VeriSign では、更に幾つかの情報を追加で登録できますし、Windows で使われている CardSpace のデータも発行できます。アカウント情報をプロバイダへ登録して、”m_arc.openidauth***.jp” という架空の OpenID を取得したとしましょう。今度は、この OpenID を使って、OpenID に対応するサービスにログインしてみましょう。このような、OpenID に対応している認証システムを実装したサービスを “RP” または古い言い方ですが「コンシューマ」と呼びます。コンシューマのサイトにアクセスすると、OpenID を使ってログインできることが分かるように、フォームが置かれています。OpenID をサポートするログインフォームには、OpenID のロゴマークが表示されているので、ご覧になったこともあるでしょう。コンシューマの OpenID 対応ログインフォームへ、発行してもらった OpenID を入力します。なお、まだ正当なユーザとして認められていないため、この段階での OpenID は “Claimed identifier” と呼ばれます。すると、コンシューマは入力された OpenID を受けて認証サーバと通信を行います(B)。プロバイダは、受け取った Claimed identifier を認証の照合データとして取り扱おうとするので、ユーザはプロバイダのログイン画面に送られます。そこで、既に登録してある情報と照らし合わせて Claimed identifier の所有者であることを認証するために、ユーザはプロバイダへログインします(C)。こうして、プロバイダへのログインが成功すると、プロバイダはコンシューマに対して、そのユーザが Claimed identifier の正当なユーザであることを保証し、そのユーザが OpenID を使ってログインできることを保証するので(ここで、Claimed identifier は “Verified identifier” となります)(D)、コンシューマはユーザをログインさせてサービスを提供できるようになります。いちどこのプロセスを経ると、次からはコンシューマの OpenID 対応フォームへ OpenID を入力するだけでログインできるようになります(E)。OpenID の認証システムを概略でご説明しました。これまでのパスワード認証で使われてきたアカウント登録と比べて、OpenID を一つ持っていれば、OpenID に対応するサービスに対してアカウント登録の手順が簡素になっている点を指摘できます。 OpenID に対応していれば、新規のアカウント登録に際していちいち住所や名前を入力する必要はなく、プロバイダへ一回だけログインすれば登録が完了します。また、その次からは OpenID を入力するだけでコンシューマへログインできるため、ID とパスワードをセットで覚えている必要はありません。しかし、便利には違いありませんが、問題はないのでしょうか。

冒頭に戻る

その2

OpenID が2005年から使われ初めて以来、さまざまなウェブサイトやブログで OpenID のセキュリティが取り上げられてきました。それらセキュリティ上の問題は、OpenID がもっている構造そのものにかかわるので、依然として検討の余地があります。そこで、OpenID にどのような問題が残されているかを、Eugene Tsyrklevich さんと Vlad Tsyrklevich さんが BlackHat USA (2007) で発表した、”OpenID: Single Sign-On for the Internet” (PDFファイル) からご紹介してみます。この発表は、現時点で検討されているセキュリティ上の難点をわかりやすく整理しているので、実際に一読されることをおすすめします。

1. URL リダイレクト攻撃

OpenID に準拠したシステムには、大きく言って6つの問題があると言われます。まず第一に、RP (“Relying Party” の略で、「コンシューマ」のことです)のネットワーク・コンフィギュレーションに不備があると、RP は認証目的で任意の URL を入力値として外部接続しますから、www.hoge.com:8080 といった悪意の URL を入力されても、そのまま www.hoge.com:8080 という URL へ接続を試みます。これはすなわち、RP がポートスキャンの道具に使われることを意味します。また、同じように http://localhost:8080 などと、RP サーバ自身に対するポートスキャンにも使われてしまいます。これらは RP が OpenID を URL として処理し、外部接続を試みるという点を利用しているので、応用すれば OpenID として、適当な大きさのファイルへ接続する URL を指定して、DoS 攻撃にもなります。これらの問題を、仮に「URL リダイレクト攻撃」と名付けます。URL リダイレクト攻撃は、まず OpenID の規格に沿った上で、可能な限り安全な運用ができるよう、実装を拡張していくことが必要です。OpenID のコンシューマ・サービスを実装するとき、例えば PHP の Zend Framework ではクラスを一つ呼び出すだけで OpenID の仕組みを導入できてしまいますが、Zend Framework のコードを理解せずに導入するのはきわめて愚かなことです。また、ファイアーウォールをも越えて外部へ接続する通信がユーザの入力値にもとづいて行われる以上、OpenID のシステムはネットワーク管理者との検討を経てから慎重に導入すべきです(逆に言って、RP の動作を説明して URL リダイレクト攻撃の可能性を指摘できないネットワーク管理者しかない会社では、RP の実装を諦める方が世の中のためです)。

2. RP-IdP のデータ交換

RP と IdP の通信では、DH鍵共有法 (Diffie-Hellman Key Agreement Method: RFC 2631) が使われています。ユーザが RP へ初めてアクセスするか、RP と IdP の間で前回確立した関連づけ (association) のキャッシュがない場合に、RP と IdP において公開鍵を共有するフェーズが始まります。RP はユーザからの入力を受け取り、IdP への問い合わせを行うに当たって、IdP と公開鍵を交換して、RP から送信するデータや IdP から送り返されるデータを安全に暗号化できなければなりません。ここで、DH鍵共有法という手続きを使って、まず RP と IdP はお互いの公開鍵を交換してから、相手の公開鍵を使ってメッセージを暗号化します。

このやりとりの過程は、「公開鍵暗号方式」としてよく知られているため、詳しい説明は割愛しますが、簡単に言うと次のようになります(ここでは『暗号解読(下)』(サイモン・シン/著, 新潮文庫)の説明を借ります)。わたし(m_arc)が、あなたとメッセージを暗号化してやりとりしたいとします。わたしからあなたに、メッセージを暗号化して送り、あなたは暗号化されたメッセージを復号化して正しく読めれば完了です。公開鍵暗号方式では、まずあなたへメッセージを送る人に、あなたは公開鍵を知らせて、「この公開鍵でメッセージを暗号化してくれ」と要求します。公開鍵は、メッセージを暗号化できますが復号化できません。そういう「一方向の」関数を使って、メッセージを暗号化したり復号化するわけです。どのような一方向の関数を使うかは、両者で同意しておく必要があります。わたしにメッセージを送りたい人は、わたしの公開鍵を使ってメッセージを暗号化し、わたしへ送信します。わたしは、自分だけがもっている秘密鍵でメッセージを復号化します。実際に計算の事例がないとはっきり理解できない場合は(わたしもきちんと計算できた方が分かりやすいです)、『暗号解読(下)』の補遺J (p.309-314.) をご覧になるとよいでしょう。

一つ申し添えると、公開鍵を交換するに当たって、お互いがお互いを本当の通信相手だと信頼できなくてはなりません。そこで、公開鍵を交換したら、まずはお互いで自分の秘密鍵を使ってデータを暗号化し、通信します。その理由は、公開鍵を使って暗号化されたデータは、秘密鍵を使ってしか復号化できないのと同様に、秘密鍵を使って暗号化されたデータは、公開鍵を使ってしか復号化できないからです。或る公開鍵を使ってデータを復号化できるということは、そのデータが公開鍵に対応する秘密鍵を使って暗号化されているということに等しいと言えます。したがって、データを暗号化した人が秘密鍵を持っている本人だと確定するわけです。

現在、OpenID の通信では RP と IdP の鍵交換に SSL での接続が要求されています。以前の仕様では DH 鍵交換法だけで鍵を共有しており、この方法は「中間者攻撃」に弱いため、現在は使われていません。また、SSL で接続していれば DH 鍵交換法を使う必要なく安全にデータを暗号化して送信できるため、DH 鍵交換法の問題はセキュリティ上のものというよりもパフォーマンスの問題と言えるかもしれません。

3. フィッシング攻撃

OpenID のセキュリティについて語られているウェブページは、その多くがフィッシングについて検討したり指摘しています。これも中間者攻撃の一つとしてよく知られており、OpenID に関しては次のように攻撃を想定できます。

Fig.6 OpenID Phishing (1)

まず、ここで問題になるのは、どの認証サーバを使うかは RP(プロバイダ)が勝手に決められるという点です。これにより、悪意の RP が自前で立てた偽認証サーバへユーザを転送できるので、ユーザは偽認証サーバであることに気づかなければ、そこで認証のために ID とパスワードを入力してしまうかもしれません。例えば、VeriSign で取得した OpenID の場合、”USERID.pip.verisignlabs.com” という文字列となっているため、このパターンの文字列が入力された場合に VeriSign の OpenID 認証で使われているフォームに似せたページを表示すれば、ユーザに怪しまれないでしょう。クッキーの有効期限が切れた等の言い訳を書いておけば、ユーザは偽フォームに ID とパスワードを入力してくれるかもしれません。また、フィッシングのパターンとしては次のようなものも考えられます。

Fig.6 OpenID Phishing (2)

Fig.7 では、OpenID で使う URL の発行サーバと認証サーバがそれぞれ異なる場合に、どのようなパターンでフィッシングが可能になるかを示しています。このパターンでは、OpenID として使う URL を、自分が運用しているサイトのドメインを使ってつくっているものとします。architectures.jp というドメインを使って OpenID を認証サーバに登録してもよいので(その代わりに、認証サーバは OpenID に該当する URL にアクセスして、 URL が実在する妥当なリソースであるかどうかを検証します)、例えばわたしが openid.architectures.jp という URL を OpenID として認証サーバに登録しているとします。このサービスを誰か他人にも提供して、hogehoge.architectures.jp という URL でも認証サーバに登録したとすれば、hogehoge.architectures.jp という URL でアクセス可能なリソースに、わたしは認証サーバとして任意の URL(任意の認証サーバ)を指定するようなリダイレクトを設定できます。したがって、Fig.7 のように偽の IdP へとユーザを転送し、あとは Fig.6 と同じようなステップで、ユーザの ID とパスワードを詐取できてしまいます。

4. IdP 認証のトレーサビリティ

次に、ひとたびユーザが認証サーバつまり IdP にリダイレクトされると、ユーザは認証サーバで ID とパスワードを入力し、認証がうまく行ったという結果を得て、RP はそのユーザに対して何らかのアクションを認可します(端的にはそのサイトの制限されたエリアへのアクセスを許可したり、一定のサービスを使えるようにします)。そして、OpenID はシングル・サインオンの一種なので、そのまま他のサイトへもログインできるようになります。しかし、セキュリティの問題として考えると、この仕組み自体がユーザのネットサーフィンをトレースするために使われてしまうという疑念は残ります。昨今では一部のベンダーと広告代理店が「ライフログ」なるコンセプトを次世代のサービスだと称して喧伝していますが、便利である以上に、この仕組みは「ネット視聴率」の計測を目的とするマーケティング活動でしかなく、計測結果が何か公的な福利厚生の向上に還元されることは絶対にありません。これと同じく、ユーザの行動をトレースするために OpenID の認証サーバ使われるという危惧を抱く人もいます。また、セキュリティとは別の話になりますが、RP のサービスを利用したいだけのユーザが、URL のホストサーバや認証サーバといった他のリソースにアクセスしなければならないというしくみは、表面的には一つの URL を使ってサービスを利用できるから「便利」ではありますが、OpenID の仕組みを構成する全てのサーバやネットワークのアーキテクチャを考えると、リソースを無駄に使っていると言えるかもしれません。

5. Reply 攻撃

次に、これは OpenID だけに限る話ではありませんが、認証の結果が有効とされた場合に RP へリダイレクトされる URL が固定されていると、そのリダイレクト先を詐取されただけで、他のユーザが「なりすまし」できてしまうという問題もあります。これとよく似たパターンで、サイトへのユーザ登録をしたときに、「本登録」と称して、本人の登録意志を URL へのアクセスで確認するというものがあります。本人の意志を確認するため、ユーザ登録で使われたメールアドレスに確認用の URL を記したメールが送信され、登録した本人がメールに書かれた URL へアクセスしない限り本登録が完了しないようになっています。この仕組みにしてもそうですが、リダイレクト先の URL やメールに書かれている本登録用の URL へ、登録した本人以外のユーザがアクセスしない(できない)という保証は全くありません。これは OpenID という仕組みが、そもそもサーバ間のリダイレクトというリクエスト方法に大きく依存しているという点で、フィッシングと同等の根本的な問題なのかもしれません。そして、認証が成功したあとでサービスにログインするためのリダイレクトでは、SSL が使われていないサイトもたくさんあります。そのため、リダイレクト先の URL を詐取されてしまうと本来の正当なユーザになりすましてサービスにログインできるという可能性は、OpenID の仕様だけでは防ぎようがないと言えるでしょう。

6. その他の攻撃

その他の攻撃としては、もちろんウェブアプリケーションですから XSS や XSRF も指摘されています。いちばん簡単そうな XSRF としては、IFRAME をウェブページや HTML メールに埋め込むという方法があるでしょう。

7. OpenID とフィッシング

さて、OpenID について懸念されている幾つかの問題をご紹介しましたが、やはり最も多くの関心を集めているのはフィッシングです。最近では OpenID の仕様 2.0 のドラフトが公開された 2007 年初頭から Ben Laurie さんをはじめとする人々が警告を発してきたように、OpenID では RP(コンシューマ)や IdP(認証サーバ)を個人が好き勝手に公開できてしまうため、ユーザ側から見て安全に OpenID を使うには、

という、最低でも三つのサーバが不正かどうかを確かめておかなくてはなりません。これまでにフィッシングへの対策として幾つかの提案が公開されていますが、たとえば Ping さんの「ブックマーク・アクセスを徹底すること」といった対策は、OpenID の利便性をワンクリックぶんだけ損なえば安全になるとされていますが(OpenID のフォームを使ったときに、RP が参照するサーバではなく、自分で選んだ IdP のフォームへブックマークからアクセスして OpenID 認証するように提案されています)、フィッシングの具体例を開発側から示して見せた Marco Slot さんによると、ブックマークからのアクセスかどうかをリファラーのあるなしだけで判定せざるを得ない現状では、ファイアーウォール越しのアクセスやセキュリティソフトを使っているユーザのアクセスと区別できないので、対策にはならないと指摘されています。では手始めに、OpenID のフィッシング対策について Marco Slot さんがまとめて反論している以下の内容をご覧下さい。

提案I: ユーザを啓蒙するんだ!
セキュリティの専門家は、ユーザにセキュリティを啓蒙することに反対などしないだろう。よく知られた言い回しを使うなら、「ユーザというものは、好奇心を満たすものに目を奪われがちで、そんなときはセキュリティのことなど忘れてしまいがちだ」(ブルース・シュナイア)とか、あるいは「あらゆるシステムは、いかにセキュアでうまく設計されていても、アホなユーザが台無しにしてしまうだろう」(ジェイムズ・ガスキン)と言えるのかもしれない。だから・・・
あなたのおばあさんは、http://f5888d0b1.07e1c41c97a.be/a15 という URL が、彼女の正しい OpenID 認証サーバではないことに気づいてくれるだろうか?
ここで待った。この問いに答えを考えたりしないでおこう。この質問は、セキュリティを語るときに持ち出すべきじゃない。ユーザ自身がセキュリティ意識をもってくれることに期待して、セキュリティというものを考えてはいけない。ユーザというものは、何の戸惑いもなしに大切なパスワードを紙に書き留めて、平らに折りたたみ、そして何のメモだったか忘れてしまえば窓から無造作に投げ捨ててしまうくせに、問題が起きたら何でも技術者のせいにするんだ。
提案II: IPアドレスが保証になるんじゃないか?
或る人々は、ユーザを IP アドレスで区別すればよいと提案している。しかし、この案はダイナミック IP アドレスや公共の端末を使っているユーザには全く使えない。特に、ユーザが公共のマシンを使っていても認証できることが OpenID の本質的な要求なので、なおさらだ。ユーザがいつも同じ単独のマシンからサービスを利用するという枠組みでものを考えるのは、時代遅れだ。
提案III: クッキーを使えばどうだろう
ユーザのコンピュータを同定するためにクッキーを使うことはできるだろう。OpenID プロバイダは認証時にログインフォームを表示しないで、クッキーの有無をチェックすればよいわけだ。しかし、クッキーそのものの有無を判定するやり方が本当にセキュアなのかどうかを検討しておかないと、クッキーを認証の通行手形に使うということは OpenID のセキュリティよりもたくさんの問題を起こしかねない。いったい何時、クッキーはマシンに保存されるのだろう。クッキーを保存するため、ユーザは何をしなくてはならないのか。まだクッキーを保存していない段階でユーザが認証を試みると、いったい何が起きるのか。もしユーザがクッキーを利用しない環境に置かれていたら、どうなるのか。もしユーザが公共のマシンを使っていて、クッキーがマシンに保存されると、どういうことになるんだろう。僕らはクッキーをどうやって削除するのだろう。そのやり方をユーザに教える必要はあるだろうか。
提案IV: 僕のお気に入りアイコンなら・・・
細かい思いつきの中でよく知られているのは、ユーザにお気に入りのアイコンを設定させるというやり方だ(なぜかモンスターのアイコンを用意しているサイトもある)。プロバイダは、ユーザが選んだアイコンをどうやって知っているんだろうか。まぁ、そうね、例えばデータベースに記録があるか(この場合は、ユーザと同じ順序で認証サーバのログインページにまで行けば、ユーザがどんなアイコンを選んだのか誰にでもわかるから、偽物のフォームを作れてしまう)、あるいはクッキーにアイコンの情報を保存するかだろう(クッキーを使ってフィッシングに対抗するというやり方は、もう取り上げた)。
提案V: ブックマークからのログインなら騙されないぜ!
幾つかの OpenID プロバイダは、ログインページをユーザへ直に表示しない。その代わりに、ユーザへログインページのブックマークを指し示して、ログインする必要があれば、いつでもそのブックマークから認証プロセスを始めなさいと言っている。このやり方なら、いつも自分が本当の認証サーバへ行っているのだと、ユーザに信じ込ませることができる。なるほど、ちょっとした防御にはなるのかもしれない。しかし、そもそも OpenID を使おうが使うまいが、認証というものが正確に言って何なのかを知らないユーザにとっては、OpenID の URL 入力ボックスにパスワード入力ボックスがくっついていても、違和感などないだろう。ユーザは面倒な手続きが嫌いだから、セキュリティなどより一刻も早くユーザ登録したいのだ。これは「踊る子豚の攻撃(”dancing pigs attack”)」とでも言えるだろう。ブルース・シュナイダーが言ったように、「ユーザはいつだって、セキュリティよりも踊る子豚に気を取られてしまう」。もしあなたが偽のログインフォームを使って騙す気でいるなら、ブックマークの手順をなくしてしまうように仕向けながら、最新の技術をユーザに紹介するかもしれない。こうした新しい利便性で大喜びさせると、ユーザはすぐにパスワードを入力してくれるだろう。かようなわけで、ブックマークからのログインは「ユーザ教育」の違ったやり方ではあるけれど、ふつうの認証手順と違っているという点でまさに危険なのだ。
提案VI: おおそうだ、クライアントの SSL 証明書があるじゃないか!
実際には、OpenID のフィッシング対策が一つだけある。それは、ウェブの通信で殆ど使われていない SSL の機能であり、クライアントサイドの証明書なのだ。これには、まずユーザが自分のマシンで公開鍵と秘密鍵を生成して、認証局から証明書を発行してもらうのである。秘密鍵を使えば、ユーザは自分が証明書の所有者であることを証明できる。しかし現状では、自分たちで証明書を作る分にはいいけれど、他の人たちに証明書を使ってもらうための現実的な手段がない(訳註:よく知られている認証局に証明書を発行してもらうには、ウェブサーバの SSL 公開鍵を証明してもらったことがあるならご存知のように、年間で数万円がかかります。ボランティアに無料で証明してもらうとしても、いったい誰が信頼できるのかという問題は避けて通れないでしょう)。だから、このやり方は解決策として妥当とは言えない。
あなたが SSL の鍵をペアで使うだけだと、現実的でないばかりか、きわめて危険だ。なぜなら、まずあなたは自分で使うかもしれない全てのブラウザで、システム管理者から容認された公開鍵と秘密鍵を、インストールしたりアンインストールしたりしなくてはならない。すると、あなたは自分の秘密鍵を使ったときに、その鍵が他のどのマシンにも保存されていないことを厳密に確証できなければならないだろう(そして、そんなことはまずできない)。
更に、あなたがどのコンピュータを使っているかによらず、SSL を使っている全てのウェブサイトは、あなたの証明書を読み込めなくてはならないだろう。その証明書には、恐らくあなたのメールアドレスだけでなく、現実の住所まで書かれている。そんなものをネットでやりとりしなくてはならないなんて、あまり好ましいとは思えない。
提案X: んじゃ、んじゃあ・・・
ありていに言って、有効な対策はないのだ。そもそもの話、これまで紹介した提案はすべて、ユーザを啓発すればとか、認証フォームをどうにか変えればといった内容に帰着しているのだが、そうしたアプローチは何にせよ根本的に間違っている・・・

OpenID を実装しても大丈夫なのか

このように見てくると、手軽さとセキュリティのどちらを取るかという話になってくるのでしょう。OpenID の採用状況を見ても、確かにマイクロソフトやヤフージャパンなどの大手企業が支持を表明しているとはいえ、これらの企業はプロバイダとしての役割を果たしているだけです。つまり現状で言える限り、ユーザからの信頼度を上げることが彼らの眼目であって、サービスの認可までサポートするつもりがあるのかどうかは不明と言えます。現実的な話として言えば、OpenID でサービスを提供している国内サイトは、広告に使えるほどの有力サイトが全くありません。もし明日から OpenID が使えなくなったとしても、当人以外は誰も困らないくらいの影響力しかありません。利用者側としては、サービスごとにログイン情報を使い分ける手間を厭わなければ、OpenID があろうとなかろうとどうでもよいと言えます。

もちろん情報が漏洩したときのリスクを考慮すれば、OpenID よりも別々のアカウントでサービスを使い分ける方が、全てのサービスを誰かに利用されてしまわない「であろう」と言える点でマシなのかもしれません。そこを、利便性という点からどこまでハードルを下げていくかはユーザ側の判断にかかっています。サービス提供者や認証サーバの提供者は(ユーザの「賢明な判断」に身を委ねるというマッチポンプをやりたいのでない限り)、これまで解説してきたような問題についてはよく弁えていると仮定できるなら、今後は Yahoo! のシールなどのようなオリジナルの防御策を提供しつつ、OpenID のセキュリティを向上するような競争を始めてくれるように期待したいところです。

先に述べたとおり、OpenID では URL ホスト、RP、そして認証サーバの三つを全て信用できなければなりません。では RP と IdP をどうやって信頼すればよいでしょうか。RP から IdP へリクエストするときには、信用できる IdP だけを利用するように、ホワイトリストを使ったリクエスト送信が紹介されています。しかし、デフォルトのままで RP ノードのシステムを実装してしまう開発者もいると思われるので、その場合はどの IdP にリクエストされるか分からなくなります。これをなぜか「認証の分散化(decentralized authentication)」などと持て囃す向きもあるようですが、OpenID の見通しとして「誰でも IdP になれる」という意味で分散化を支持するような議論は、およそ現実的ではありません。それとも、RP の運営者は、信頼できる IdP が見つかって妥当なホワイトリストを提供できるようになるまで、ニセ IdP に認証されたユーザのアクセスを認可してしまうというリスクを垂れ流すつもりなのでしょうか。いちユーザとしての私見を言うなら、OpenID は、いわゆる “lightweight” なウェブサイトだけに利用すべきです。ユーザ登録した後で実際に他のサービスでも使っている個人情報(銀行口座番号やカードの名義など)を、プロファイルへ追加するようなサイトでは、OpenID を使うべきではないと考えます。それはつまり、OpenID を使わずに従来の手順でユーザ登録しても、せいぜいメールアドレスや生年月日ていどの「個人情報」を、後でプロファイルに登録できるくらいしか情報を保持していないような、ユーザの情報をあれこれ要求しないサービスにとどめる方がよいということです(いま、「個人情報」と括弧付きで書いたのは、これは捨てメールアドレスやウソを記述してもよいからです。私見では、多くのサイトではプロフィールなどといった自己顕示欲をくすぐる手口で、不必要に個人情報を取得していると考えています)。

また、RP として OpenID をサポートするようなサイトを構築するかと言われると、それも躊躇せざるをえません。サービス提供側にしてみれば、ユーザ登録フォームでユーザの属性を(ときには不必要なほど)取得できていたにも関わらず、OpenID でユーザ登録できればその機会が失われます。この点を懸念する声が、営業もしくはマーケティングから挙がると思うので、OpenID を導入するための社内的なハードルは高いと思います。マーケティング部門を説得するには、IdP を運用すれば、ユーザが他のどういうサービスを利用しているのかが分かり、マーケティングの道具として使えると言えばよいかもしれません。しかしながら、そもそもユーザ認証を自由に分散化するというコンセプトは恐らく実現せず、せいぜい Yahoo! や VeriSign といった、あらかじめユーザにあるていどは信頼されている IdP だけの寡占状態となるでしょう。URL の発行元ですら信用に値しないのが OpenID の難点になると思われるので、VeriSign のように URL の発行と IdP を兼ねることで安全性を保証するようなサービスが増えてくれば、初期の理念とは逆向きに進むのではないかと思われます。中小規模の制作・開発会社としては、短期的には数日で IdP サーバをリリースできても、せいぜい技術的なプレゼンテーションといった意味合いしかないでしょう。一般ユーザにまで普及するくらい長期的なスパンでみると、中小規模のIT企業が手を出して収益に結びつくようなものではないと言えます。

冒頭に戻る

その3

次に、OpenID の仕様で言及されているセキュリティ上の論点をご紹介したいと思います。ここまでの記述について誤解を生じるかもしれないので申し添えておきますが、わたしは OpenID についてネガティブな論陣を張っているわけではなく、保留すべき点が幾つもあると言っているにすぎません。また OpenID の実装をあれこれ考察したり動かしてみている方々に水を差すつもりもなく、どちらかと言えばプロパガンダ的な文脈で煽っているだけのIT系メディアに異議を表明しているにすぎません。

これまで見てきたような、OpenID に関するセキュリティ上の問題点については、それぞれの RP や IdP で個々に対策を施したり、また OpenID の推進団体へフィードバックして仕様の水準を上げてゆけばよいと期待できます。そこで、上記で説明してきた問題点について、OpenID の仕様ではどのような対策が提案されているかをご紹介したいと思います。

OpenID 認証規格に見る提案

それでは、昨年12月(2007年12月)に公開された「OpenID 認証 2.0 最終版(OpenID Authentication 2.0 – Final),日本語訳」を紐解いてみましょう。ちなみに、日本にも Six Apart、日本ベリサイン、野村総研が発起人となる OpenID ファウンデーション・ジャパン という団体や、株式会社アセントネットワークスが運営している OpenID の推進サイトはありますが、まだ 2.0 規格の公式翻訳は公開されていません*。そのため、注意は必要ですが非公式の翻訳を参照されるとよいでしょう。また、株式会社フィードフォースが規格の概略をまとめてくれています

*2011年9月現在、OpenIDファウンデーションにて規格の文書が公開されています。そのため、以下でわたしが言及している言葉と訳語が違っているかもしれません。

セキュリティ対策は規格 2.0 の第15節で言及されており、まず 15.1.1 の盗聴攻撃(eavesdropping attack)については、「盗聴を防ぐために接続時のトランスポート層の暗号化を使う。加えて、TLS を使わなくてもこの攻撃を防ぐことはでき、それはやりとりされるメッセージを照合するあいだ、nonce をチェックすればよいだろう」と説明されています。非常に簡単な言い方をすると、この説明の意味は「認証要求のやりとりには SSL 通信を使え」ということです。認証サービス(と、たいていはそれに付随するアクセス権限の付与つまりはログインサービス)を提供するわけですから、常識的に見ると当たり前のことを言っているようにも思えます。また、そもそも OpenID による認証は、IdP であれ ID に使うドメインのホストであれ、サーバの認証ができていなければユーザから信用などされないでしょう。とは言っても、JIS Q 15001:2006(プライバシーマークの規格と言ってもよい)の実務などをしていると、問い合わせフォームやユーザ登録フォームを SSL 通信環境下で実装していない企業は、呆れるほどたくさんあります。したがって啓蒙的な意味合いもあるのでしょう。なお、15.1.2. 中間者攻撃(Man-in-the-Middle attaks)を見ると、幾つかのパターンは提案されていますが、最も実効性の高い方法としては、こちらも SSL 通信を導入すればセキュリティ強度を上げられるとされています。15.1.2.1. RP のプロキシによる詐取という中間者攻撃の一種についても、OpenID 認証サーバとエンドユーザの通信を暗号化するよう示唆されていると見做してよいでしょう。次に、ユーザエージェントについて言及されており、ユーザエージェントがマルウェアやスパイウェアに感染しているときは OpenID の規格において何らかの対策を定めても規格の守備範囲を超えてしまうため、最低限の勧告としてはユーザエージェント側で実行されるスクリプトに依存するような認証プロセスを実装しないよう、要求されています。したがって、OpenID を紹介する一部の記事には Ajax を使って簡単に認証できるといった売り文句を見かけますが、もちろんこれはセキュリティとのトレードオフになることを分かっている筈の読者に述べているとのだと、好意的に解釈する方がよいでしょう。ログインフォームの実装として、JavaScript を必須としている事例には、自動プログラムによるアクセスを妨害するという発想があるのかもしれませんが、これはキーボード操作やマウス操作をシミュレートするマクロプログラムでどうにでも対策できることです。

特にデザイナーさんが理解していない点として、そもそもクライアント側で何をしていようと、サーバが受け取るのはプロトコルに従って正規化されたデータだという事を挙げられるでしょう。言ってみれば、脆弱な条件において中間者攻撃が成功してしまうのは、サーバには、送られてきたデータが「あなたが直に入力したデータ」かどうかを判定する能力がないからなのです。それゆえ、しばしばウェブ制作の現場で耳にする話ですが、フォームの送信ボタンを jQueryscript.aculo.us で表示すればロボットに自動投稿されたりしないであろうと言うのは、根本的にインターネット上のデータ通信の仕組みを誤解していると言わざるを得ません。サーバという機器は、規定のプロトコルに従って、許可されたポートを通ってくるデータであれば、ファイアーウォールやセキュリティ機能付きのスウィッチングハブなどが導入されていない限り、それが自サイトのフォームから送信されたのか、それとも外部から送信されたのかを区別しません。したがって脆弱な条件の下では、ソケット関数などを使って、フォームの値を受け取る処理系のコードへ任意の値を送信できてしまいます。逆アクセスランキングを使っているアダルトサイトなどに対しては、PHP や HSP で書かれたユーザエージェントで偽のアクセスを送るのが昔からの常套手段です。そして、IE や Safari といったアプリケーションと、スクリプト言語で作られたアプリケーションを、「本物のブラウザ」あるいは「ヴァーチャルなブラウザ」と区別するのは、ネットワークプロトコルの原理を全く理解していない人のセリフだと言えるでしょう。しかし、問題はデザイナーだけにあるわけでもなく、処理系のコードへ直にデータを送信できないようにすると称して、処理系の側で HTTP_REFERER をチェックするといった、都市伝説のようなコードをいまだに書いているプログラマもいます。セキュリティの問題は常に業界全体の課題であると言えます。

次に、15.3 User Interface Considerations(ユーザインターフェイスについての考察)では、認証中のプロセスをユーザに見えるようにして、正常なプロセスとフィッシングとを判別しやすいインターフェイスを提供すべきだと書かれています。なるほど、フィッシング対策の一つとして、ユーザーインターフェイス上の改善がたくさんあると思われ、現に最近のブラウザでは HTTPS/HTTP の各プロトコルに応じてアドレスバーに色を付けたり鍵マークを表示するなどの工夫をしています。また、サーバの証明を厳しくチェックしてメッセージウィンドウを表示するといった動作もするようになりました。ただし、こうした内容はガイドラインとしての効力しかなく、事実上は愚かなプログラミングや実装あるいはページデザインへの牽制としては弱いと言えます。ややもすると、「OpenID オタクだけが知っていること」として、セキュリティやマネジメント嫌いの人々からは積極的に無視されるものとなりかねません。

思うのですが、これだけユーザーインターフェイスの不備によってセキュリティ上のリスクが高くなるという事例が出てきているにもかかわらず、ウェブデザイナーに殆どセキュリティ意識がなく、それどころかセキュリティ管理やアクセシビリティへの準拠は自分たちのクリエーティブを制約するといった、子供のような茶飲み話が横行しているのは、何が原因なのでしょうか。一つには、日本では海外とは異なり(意外に思う人も多いと思いますが)極端な分業が進んでいるという点が挙げられます(肩書きの種類は海外の方が多いと思います)。海外では、ウェブデザイナーも TCP/IP の概略やネットワークシステムのアーキテクチャを一通りは学び理解しているのが当たり前ですが、日本では戦後教育の影響なのか、デザイナーの個性を伸ばすために仕様や規格といった「管理」の概念に結びつくルールの類を、専門学校や大学でデザイナーに殆ど教えていないと言えます。また、教えている講師がそもそも広告・印刷・出版といった業界出身の人々で占められているため、極論を言えば「インターネットがない時代にデザイナーをしていた人々が、インターネット上の媒体でデザインする人に教えている」という構図が残っており、負の連鎖をもたらしていると思われます。海外で働いたことがある人はたいてい指摘しますが、海外で「ウェブデザイナー」と言えばスクリプト言語やサーバの運用に精通していても全く普通と言える職能であって、スタイルシートと XHTML をコーディングするだけの職能といった区別がやたらと(海外には殆ど存在しない肩書きなのに、なぜか横文字で)細かいのは日本だけと言えるでしょう。「したがって」職責が異なるので、セキュリティについて配慮しなくても良いというロジックが腑に落ちるようなのです。

さて、次の 15.4 HTTP and HTTPS URL Identifiers を見ると、適当な訳がないので仮訳すると次のようになります。

前節で取り上げた OpenID プロバイダ認証の URL とは違って、これらのタイプの識別子(ここでは URL Identifiers)は前もって議論されていたので、ここで再び取り上げる価値がある。先に述べたように(11.5.2)、スキームが(HTTP と HTTPS で)異なっているだけの URL を制御するような、エンドユーザの表現として推奨された方法は、HTTP の URL から HTTPS の URL へリダイレクトするという方法でした。RP は、初期動作フェイズ(7.1)と探索フェイズ(7.3)のあいだは HTTP の URL を保存してはならず、それは HTTPS の URL へとリダイレクトして使う要求識別子(Claimed Identifier)でなければならない。

この部分を見ても、これまでと同じく HTTPS つまり SSL 通信を使って認証フローを進めるべきだという主旨は分かります。そして OpenID の話だけに限らず、既に多くの企業では、問い合わせフォームなど個人情報を取得するようなインターフェイスを実装するときに、フォームのページや処理系への転送は HTTPS 通信を前提にしているため、特に奇異な内容ではありません。また、昨今では SSL の証明取得費用が下がっているため、SSL 通信の導入はハードルが低くなっています。そして、最後に 15.5 Denial of Service Attacks を見ておきましょう。概してサービス拒否攻撃はどのような公開ウェブサーバに対しても行われる可能性はありますが、OpenID の処理系に特有の問題があるとすれば、どのような点を考慮すべきでしょうか。まず、”since there is nothing in OpenID protocol messages that allows the OP to quickly check that it is a genuine request(OpenID プロトコルのメッセージには、プロバイダから見てそのメッセージが本物のリクエストであるかどうかを即座にチェックさせるような内容がないので・・・)” と述べられているように、RP からのリクエストが止めどもなく繰り返されることで DOS 攻撃になってしまう可能性が指摘されています。サービスを提供できなくなるほどの負荷がかかるのは、”the association phase as each message requires the OP to execute a discrete exponentiation(関連付けフェイズでは、個々のメッセージがプロバイダに離散的な累乗を計算するよう要求する)” と述べられている部分です。OpenID では、関連付けのフェイズで RP とプロバイダが秘密鍵を共有するにあたって、メッセージのやりとりを DH(Diffie-Hellman)鍵交換という方式にしたがって行います。この方式を定義した RFC 2631 をご覧頂くと、もちろん暗号の方式ですから復号である離散的な対数を計算するのは難しいのですが(離散的な対数を多項式時間内に効率よく計算する方法がない、というのが暗号の難しさを保証しているためです)、逆の離散的な累乗(冪乗)は容易です。この事情は、或る式を展開することと、展開した式を逆に因数分解することを比べてみれば、因数分解の方が手間がかかるのでお分かりかと思います。但し、計算がアルゴリズムとして容易であることと、計算に使われるマシンパワーの話は区別しておかなければなりません。そして、ここでは離散的な累乗の計算をいちいち IdP にリクエストするような RP の動作が可能であるという点で DOS 攻撃の可能性が示唆されています。したがって・・・

この点(IdP にリクエストが繰り返されること)は著しく危険ではあろうが、このような攻撃と戦うときの助けとして、OpenID プロバイダはよく普及している IP ベースのレート制限と接続禁止テクニックを簡単に使える。そして、OpenID プロバイダは、”openid.realm” や “openid.return_to” の値を含むリクエストを判定して、アクセスを禁止することもできる。

このように、 15.4 や 15.5 あるいは仕様の中では次に述べられている 15.6 も同じく、プロトコルの仕様を正しく理解してサーバを設定し、プロトコルにはさまざまなバリエーションがありうると理解することによって、適切にサーバ(そして利用者)を保護できるとされています。

[※ 以下の文章は2008年当時の注釈であることにご注意ください]

今回、訂正版としておりますが、訂正した箇所はこの最後の文章です。もともとは本文の後で「雑感」として書いたものですが、テーマの主旨と全く異なるところでいざこざの元になると思われたため、謹んで取り下げさせていただきます。しかし、こちらで「罪状」を勝手に取り下げると隠したことになり、更に事情が悪くなることもあります。そのため概要だけ「自白」すると、別にサイボウズ・ラボさんだけを想定して言ってたわけではありませんが、OpenID の普及に熱心な方の代表として、サイボウズ・ラボの山口(ZIGOROu)さんの記事を挙げて皮肉を書いた訳ですね。しかし、彼が書いているものの多くは私がここで書いている記事のよい参考ですし、技術については教えられることばかりですから、特にそれ(いささか過剰とも思える表現)以外の点で論争する意図はなかったわけです。もちろん、彼が所属しているサイボウズ・ラボは「短期的な収益化や既存の自社(グループ)製品に固執することなく、研究開発テーマを設定」すると企業活動をうたっているので、収益に結びつくかどうかに固執しないで OpenID と関連技術を研究され、色々な場所で発表されていることは敬服に価します。ただし、企業の名前を出して発言されているからには(既に「OpenID ハッカー」との呼称までありますし)、やはり企業の一社員としてプレゼンスが考慮されているのは当然だと思われるので、「IR対策」という面もあるのだろうと言っただけです(逆に全く自分のプレゼンスを考慮していないなら、企業名は出すべきではないと考えます)。私としてはその程度のリテラシーは読む側にも必要だろうと書いただけなのですが、「IR対策」という言葉は、表向きだけの嘘っぱちか、あるいは風説の流布とまではいかなくても限りなく自作自演に近いプロパガンダという悪いイメージが強いためか、どうやら私の文章は「罵倒」と解釈されたようです。もちろん、これは本意ではありませんから、お詫びして取り下げようと思います。というわけで、露出度も知名度も反論に利用できるメディアも全く違う方を相手にするのは正直なところ気が引けますし、この点であれこれ陰湿な応酬を続けても(笑)、恐らく何の建設的な結果にも至らないと考えられます。

冒頭に戻る

その4

少し「セキュリティ」という話題から離れます。ここまで読んでいただいた方に感想を聞いていると、確かに OpenID を使うと何が「良い」のかが分かりにくいという点が一つの反省材料になりました。そこで、今回は改めてサービス利用者の目線で OpenID をご紹介してみたいと思います。

言われてもみると、目にする範囲で言えば OpenID について取り上げているメディアは、まだまだ少ないと言えるでしょう。せいぜい私にしても、『Web Site expert』(2008.7)、『WEB+DB Press』(2008, vol.45)、それから『週刊アスキー』(2/1号)で見かけたくらいです。ですから、確かにまだ広く知られていないという理由があったとすれば、いわゆる IT 系のメディアで「分散」とか「オープン」といった言葉が連呼されがちなのも仕方がないと言えるかもしれません。そこで OpenID を使う手順について、既にご存知の方々にはくどくなりますが、以下のとおり一例をご覧いただくことは有益だと思いました。

OpenID を利用してみる

一回目の記事で OpenID の概要をご紹介しましたが、具体的にどう使うのか分かりにくい説明でした。そこで、今回は OpenID が使えるサービスを利用したいときに、どうすればよいかを具体的に見てみましょう。

OpenID を使う(1)

ブログの記事へコメントを書きたいとき、ニックネームやメールアドレスが必要になることはよくあります。ありふれたことではありますが、入力する側にしてみると煩わしいのは確かです。OpenID を使うと、そうした煩雑な作業が幾らか緩和されます。上記は(OpenID に関心のある人は知ってると思いますが)、或るブログのコメント入力フォームです。ここに、「OpenID でサインインする」というリンクがつけられています。では OpenID を使うと、ふつうに名前や URL を入力してからコメントを記入する場合と比べて、どう変わるのでしょうか。

さきほどのリンクをクリックすると、OpenID のサインイン専用フォームが出てきます。画面キャプチャーのいちばん下に書かれているように、OpenID でサインインしてからコメントを投稿すると、そのコメントは OpenID と紐づけられます。したがって、あなたが別のブログでコメントを書いても、OpenID でサインインしてから書いたのであれば、そのコメントも OpenID と紐づけられるので、それぞれ異なるブログで書いたコメントであっても、どちらも同一 ID のコメントであると言えるようになります。別々のサービスに同じ OpenID でサインインできるというのは、もしコメント投稿者としての同一性を保ちたいのであれば、よく似たスペルの OpenID を使う他人が存在しうるという点を差し引いても、ひとまず便利と言えます。それでは、さっそく OpenID を取得してみましょう。

今回は、VeriSign 社の Personal Identity Provider を利用します。OpenID プロバイダ(または認証サーバ)は、他にも OpenID.net や Yahoo! や livedoor など、たくさん運営されています(海外のリストは、OpenID.net Wiki に掲載されています)。

VeriSign PIP にてサインアップを始めると、通常のユーザ登録と同じ手順が始まります。あらかじめ OpenID プロバイダに登録しておいてやっと OpenID が使えるのですから、初めて OpenID を使う人には煩わしいかもしれませんが、最初の一度だけは丁寧に登録してみてください。VeriSign PIP は、VeriSign が運用しているという点で、個人が運用している OpenID プロバイダよりも常識的な意味での信頼度は高いと言えるでしょう。

そんなこんなで、アカウントの登録が終わると、晴れて自分自身の OpenID が発行されます。VeriSign PIP で発行される OpenID は、画面に出ているように、アカウント名の後に「.pip.verisignlabs.com」という文字列が続くという点で同じパターンとなっています。これはこれで先の記事で説明したように、OpenID プロバイダに合わせてサインインのページデザインを切り替えるといった技巧が使いやすくなると思いますが(クローキングとかドアウェイに似ていますね)、今回はあまり議論しないでおきます。ともかく、「************.pip.verisignlabs.com」という OpenID が仮発行されたところまでやってきました。

アカウントの登録はできましたが、よくあるユーザ登録の手順と同じく、VeriSign PIP でもメールを使ったアクティべーションの手続きが残っています。もちろん、このやり方にも一長一短はありますから、アクティべーションを使っている方が「よい」とか「堅牢なサービス」だというわけではありません。ともかく、上記のようにアクティべーションを促すメールが届きますので、アクティべーションしましょう。

すると、アクティべーションが完了して、本登録された OpenID が表示されます。

OP では、OP に登録しているアカウントの管理画面で、セキュリティ対策として「アイコン」の登録を勧めている場合があります。VeriSign PIP の “personal icon” や Yahoo! JAPAN の「ログインシール」と呼ばれているものがそれに当たります。

アイコンを登録してみたところです。

では、取得した OpenID を使ってみましょう。はじめのブログに戻って、OpenID でサインインします。

すると、VeriSign PIP にリダイレクトされるので、VeriSign PIP の登録情報でログインします。

VeriSign PIP の場合、ログインすると「どこからリダイレクトされたのか(RP)」の確認と、その RP に対してアソシエーションハンドルを渡す際の有効期限をユーザ自身で設定できます。ちょうど、ID とパスワードを使ってログインするサイトでセッションに有効期限があるのと似ていますが、セッションの場合、ユーザ自身がコントロールできるのは「受け入れるか拒否するか」だけであり、具体的な有効期限は設定できません。通常、ここはその OpenID の利用目的によって使い分けるのがよいでしょう。ずっと使える方がいいなら、期限なしか長期の期限を設定してもよいでしょう(ちなみに Twitter のセッションは 20 年有効で設定されています)。あるいは、都度で認証フローを通したいなら、RP で認可するフェイズへ渡した後はすぐにアソシエーションハンドルを無効とする設定にすればよいでしょう。

OP での認証が終わると RP にアサーションが返されて、殆どの場合は認可のフローに繋げられて RP のサービスを利用できるようになります。上記のように、OpenID でサインインしていることが示されて、その OpenID の所有者としてサイトにサインインしていることが分かります。

コメントの投稿フォームは上記のように変わっています。いちばん最初に見た図から変わっていますね。名前だけ入力して、あとは投稿すればOKです(投稿すると、OpenID は名前の文字列にリンク先として設定されます)。

なお、VeriSign を利用している場合は、フィッシング対策として FireFox 用のアドオンが配布されていて、これを使うとアドレスバー(またはステータスバー)に、ログインステータスを表示できます。また、フローの間違いがあると上記のようなエラーページが表示されます。ただ、VeriSign PIP のアドオン(シートベルト)を導入すると、OpenID のフォームを使うときに毎回 PIP へのログインを促す画面がオーバーラップで表示されるので、他の OP を使うときに煩わしいかもしれません。

最後に

今回は、議論をしないというルールで書きましたので、殆ど流れを追っただけになりました。なので、少しだけ議論しておこうと思います。OpenID を使うと何がいいのか? これには、幾つかの回答があるでしょう。まず、上記のような手続きを経ると、別のブログにコメントを書くときも、そのブログが OpenID のサインインに対応していれば、同じ ID をもつユーザとして利用できるというのが、分かりやすい利点です(これは、全てのサービスが OpenID に対応しないしすべきでもない以上、限定的な利点と言った方がよいでしょう)。もちろん、これは同一 ID を使えという話では全くありません。一つの OpenID でも「ペルソナ」を設定して、個々のサービスごとに登録内容を使い分けたりもできるので、これまで異なるサイトごとに違う登録情報を入力していた人も、OpenID を活用できます。実際、私も普段はウェブサービスサイトやメーリングリストに登録するときは、とりわけ海外のものでは “First Name” という入力覧に、そのサービスや ML の名称そのものを入力しています(すると、スパムが来たときにどこから漏れたかが分かる場合があります)。これと同じ事が、一つの OpenID でもペルソナを使い分けることで可能になります。

すると、少なからずこう問う人がいるはずです。「同じ ID として同一性が保証されるということは、もし OpenID でしかサインインできないサービスがあると、そういう同一性を伏せたい人はどうなるの?」もちろん、ペルソナを使い分けてスクリーンネームを別にすればよい場合があります。しかし、さきほどのサイモンさんのブログのように、OpenID がリンク先として設定されている場合は、違う surname にしていてもステータスバーで確認すればすぐに OpenID が確かめられてしまいます。こういう時は、OpenID のプロバイダは数多く存在しているので、OpenID を幾つか所持して使い分けてもよいでしょう。ただ、それをやりすぎると、これまでと同じく「ID とパスワードを何ペアも覚えるのが面倒だ」とか、「面倒なのでパスワードを全て同じにしてある」とか、「面倒なのでパスワードは短く “qp” にしてある」といった状況に戻ってしまいます(まぁ、OpenID の使い分けの場合は、わざわざそうする理由が自分にあって、サービスの方から要求されているわけではないので、自分でどうにかしろという話なのですが)。

それから他の利点として、このようなフローを経てからコメントが投稿できるので、コメントスパムの投稿が難しくなるという理由で、サイトを運営したりコメントを読むユーザの利益となります。ただ、ユーザというものはセキュリティとかヘルプデスクとかノイズの低減を「利点」とか「本来は人手や経費がかかるサービス」として理解しない性質があるので、これは具体的に何年か運用していって「ブログを放置しても、バイアグラとか出会い系とか3流ウェブデザイン会社とかの宣伝は、投稿されなくなったでしょう?」と説明するしかありません(コメントスパムはどのみち手作業でも投稿できますし、そもそも何が「スパム」なのかは予め条件を指定できるものではありませんから、完全になくすことは原理的に不可能ですが)。

このように見てくると、サービスの利用者として一つの ID だけでよいというのは、現実には限られた条件でしか当てはまらない利点だと言えます。OpenID 対応サービスだけを利用しているような人にとっては、非常に便利なものです。それは間違いありません。しかし、「一つの ID でさまざまなサービスを使えます」という宣伝文句の怪しい点は、「さまざまなサービス」の中に、多くのユーザが使っているサービスは殆ど含まれていないという事実があります(現状では言い切ってもよいでしょう。StackOverlow にログインできて嬉しいというエンドユーザが、業界人を除いていったい世界中に何人いるというのでしょうか)。しかしともかく、ユーザをはじめ、開発側の先頭に立っている人たちが OpenID の利点を熱心に説明することは意義があります。

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook