第6回　設計・運用の観点から考えるOpenIDの課題

これまでの連載では、ruby-openidライブラリやRailsのOpenID Authenticationプラグインを使いながら、主にプログラムの観点からOpenIDでログインできるWebサイト（RP, Relying Party）を構築してきました。連載の最後に、設計・運用の観点からOpenIDの課題についてみていきましょう。

OpenIDに登場する「ID」のまとめ

OpenIDではいくつかの「ID」が登場します。これまでの連載で作成したサンプルを例にして、OpenIDに登場する「ID」をまとめてみましょう。

ユーザ提供識別子（User-Supplied Identifier）: 利用者がログイン画面で入力するURLです。自分のOpenIDアカウント名を入力することもできますし、代わりにyahoo.comのようにOPのドメインを入力することもできます。特定のOPのみのログインを許可するようなRPの場合、セレクトボックスから選択させるようなインタフェースにすることもあるでしょう。
ユーザ主張識別子（User-Claimed Identifier）: 本連載で「OpenIDアカウント名」と呼んでいたIDです。RPが利用者を識別するためのIDとなります。OPからRPへは、このIDが渡されます。

さらに、利用者にとってのIDはこれだけではありません。 OPにログインする時のID（はてなやYahoo!やlivedoorなどのアカウント）がありますし、今回のサンプルのようにRPにユニークなIDを登録する場合もあります。 OpenIDでIDが一つになるどころが、逆にIDが増えてしまったような印象も受けます。 OpenIDを使うことで、利用者のとって逆に管理が面倒になるようでは困りますね。

URLをIDに使うことによる問題

インターネットで爆発的に増えるIDを整理するために登場したOpenIDですが、なぜ逆に煩雑になるように感じるのでしょうか。一つの理由は、「⁠URLをIDとして使う」ことにあるのではないでしょうか。 OpenIDに対応したRPが増えれば、図1のように一つのIDで複数の対応サイトへログインできるようになります。

このID（Claimed Identifier）はURLであるため、利用者がIDとして認知しずらいという問題があります。最近はメールアドレスをIDとして使用するWebサイトも多いですが、利用者にとってメールアドレスが「自分のもの」と認知しやすいのに対して、ブログを書いているような一部の利用者でないとURLは「自分のもの」と思わないでしょう。

一つの対策は、利用者にIDを意識させないことです。連載の第1回で見たように、Yahoo!のOpenID実装はユーザにOpenIDのアカウント名を意識させないようになっています。 OpenIDでのログイン時に「○○でログイン」というボタンを用いるのであれば、利用者はログイン時にOpenIDのアカウント名を意識しないですみます。しかし、RPへログインした後は、RP側でもユーザのIDが必要になります。今回の連載で作成したようなミニブログサービスでは、ユーザのIDを画面上に表示する必要があったため、図2のようにOpenIDでのログイン後にRPローカルのIDを登録しました。

一方で、利用時にIDを意識しなくていいようなサービスであれば、RPローカルでのID登録は不要になるでしょう。そのような軽いサービスのほうが、OpenIDの導入は容易であるかもしれません。

もう一つの対策はURLの代わりにシンプルなXRIを使うことです。 OpenIDでは、利用者が覚えにくいURLの代わりに、XRIという覚えやすいIDを使う方法も提案されています。 XRIとURIは、DNSのホスト名とIPアドレスの関係に似ています。 XRIが普及することで、OpenIDを利用する上でのIDの覚えにくさは解消されるでしょう。しかし、XRIを利用するためには別途XRIサーバに自分のIDを登録する必要があり、現時点では誰でも簡単に使える状況になっていません。そのため、XRIについての説明は割愛しますが、XRIが普及すればURLを使うことの分かりづらさは根本的に解決されるでしょう。

OpenID Providerのサービス停止に備える

利用者やRPにとってOpenIDを使ってログインするということは、認証をOPに任せることになります。 OpenIDが普及しつつある現状では、これからも新規にOPを始めるところが増えていきます。そうすると、「⁠これまでは○○サービスでログインしていたけど、これからは××サービスでログインしたい」という要望もでてくるでしょう。

さらに大きいのは、OPがサービスを一時的・恒久的に停止した場合に、RPへもログインできなくなるという問題です。そこで、パスワード認証の場合に利用者がパスワードを変更できるように、OpenID認証でも利用者がOPを変更できるようにすることが考えられます（図3⁠）⁠。

利用者はRPローカルのIDと、複数のOPのIDを結びつけることとなります。複数のOPでログイン可能であれば、一つのOPがサービスを停止しても他のOPでログインすることで、RPのサービスを継続して利用できます。

また、連載の第4回で作成したように、OpenID認証とあわせてRP個別のパスワード認証機能を併用する場合もあります。この場合は、パスワード認証を利用するユーザがOpenID認証に切り替えたり、逆にOpenID認証を利用するユーザがパスワード認証に切り替えられると、より利便性が向上します。

利用者がOpenIDアカウントを忘れた場合への対応

通常のパスワード認証で最も多い問い合わせは、利用者が自分のIDやパスワードを忘れることでしょう。同じようにOpenIDでも、利用者がOpenIDアカウント名を忘れる可能性があります。「⁠○○でログイン」ボタンのように、OPのドメイン名を選択させる場合は忘れることは少ないでしょうが、OpenIDのアカウント名をそのまま入力させる場合は利用者がアカウント名を忘れることを想定しておいた方がよいでしょう。

前述のように複数のOPを登録できるようにすることでアカウント名を忘れるリスクは減ります。また、利用者のメールアドレスを登録するようなサービスであれば、そのメールアドレス宛にOpenIDアカウント名を送るリマインダ機能を用意することも考えられます。パスワード認証の場合はパスワード変更用のURLをメールに記載しておくことになりますが、OpenID認証の場合はアカウント名を送るだけですので、より安全と言えます。

ただし、利用者のメールアドレスをいつ登録してもらうかは、検討の余地があります。パスワード認証の場合はユーザ登録時にメールアドレスの到達確認を行うことが多いですが、OpenID認証で同じような到達確認を行うと、利用者は「OpenIDでのログイン」と「メールの到達確認」の2段階の登録手順を踏むこととなり、余計に煩雑な印象を与えてしまう可能性があります。連載の第3回でご紹介したSREGのように、OPからRPへメールアドレスを通知するような仕組みが普及すれば、この状況は変わるかもしれません。それまでは、必要に応じてRPへ個別にメールアドレスを登録してもらう仕組みが必要でしょう。

WebAPIを提供する場合の認証をどうするか

近年のWebアプリケーションは、利用者がWebブラウザで利用するだけとは限りません。専用のクライアントアプリケーションや、別のサイトのWebアプリケーションから接続するためのWebAPIと呼ばれるインタフェースを用意することも増えています。当たり前ですが、WebAPI経由で利用者の情報を操作する場合にも認証が必要となります。パスワード認証の場合は、WebAPIにBasic認証などを適用することが可能ですが、OpenID認証の場合はそうはいきません。 OpenID認証では、利用者とOP間の認証方式までは規定していないため、WebAPI経由でプログラム同士が認証するようなケースには適さないのです。

一つの解決策は、前述のようにRPでも個別にパスワードを登録できるようにしておき、WebAPI経由の認証にはそのパスワードを使うことです。しかし、そうなると利用者が管理するパスワードが増え、OpenIDを利用するメリットがあまりありません。また、別のサイトのWebアプリケーションからWebAPIを利用する場合に、IDとパスワードで認証することにそもそも危険があります。そのサイトに悪意があった場合に、パスワードを悪用することで利用者の持つすべての権限が利用されてしまうためです。

より望ましい解決策は、WebAPIの認証にパスワードを利用するのではなく、「⁠トークン」と呼ばれる別のパスワードのようなものをWebAPIを利用するアプリケーションごとに発行することです。このような仕組みを実現するOAuthというプロトコルが提案されており、各言語用のライブラリも公開されています。

信頼できないOPを利用することによる問題

OpenIDの特徴は、OPという認証サーバが分散していることです。インターネット上のサーバであれば、誰でもOPになることができるため、OPのセキュリティレベルにはばらつきがあります。そのため、利用者がセキュリティレベルの低いOPを利用することによって、第三者が利用者になりすましてRPにログインする危険性も考えられます。

自由にOPを選択できるというOpenIDの仕組みの上で、どのようにOPを信頼するかはOPのReputation（評判）問題と言われています。

OpenIDの背景を考えると、信頼できるOPを選択するのは利用者の責任であり、それをしなかったことによる責任は利用者に帰すとも考えられます。ユーザ登録時に同意してもらう利用規約などで責任を明確にすることも重要です。しかし現実的には、OPのReputation問題をすべて利用者任せにすることは、利用者の負担が大きすぎるでしょう。

利用者がOpenIDの利用を躊躇して、結局RPのサービスを使ってもらえないかもしれません。そのため、第三者によるなりすましが問題になるようなサービスを提供する場合は、OpenIDによるログインを許可するOPをRPが明示的に指定する方式も考えられます。このようなホワイトリスト方式は、連載の第5回で作成していますので参考にしてください。

連載のまとめ:OpenIDのメリットとデメリット

6回に渡ってお伝えしてきた連載もいよいよおしまいです。 OpenIDに対応したRPを構築するためのプログラム方法から、サービス提供上の課題までを取り扱ってきましたが、いかがでしたでしょうか。連載の最後に、OpenIDを採用することのメリットとデメリットを整理しましょう。

はじめにメリットですが、一番大きいのはユーザ登録の敷居が下がることです。何かのサービスを利用する際に、ユーザ登録というのは利用者の心理的な負担となります。「⁠○○のアカウントがあれば面倒なユーザ登録は不要です」となれば、試しにサービスを利用してみようと思う利用者は増えるでしょう。特に、大手のWebサイトがOPのサービスを提供していることから、多くの利用者が知らず知らずのうちにOpenIDを利用できるようになっています。また、従来であればCAPTCHAやメールの到達確認などでbotなどの不正なユーザ登録を防ぐ仕組みが必要でしたが、OpenID認証ではすでにOP側のサービスを利用している「質の高い」利用者であることが期待でき、CAPTCHAなどの仕組みをRPで用意する必要もなくなります。

一方で、RP側で従来のパスワード認証を併用する場合には、パスワード認証とOpenID認証の双方に対応するためにコスト増となります。これはRPが提供するサービスの規模やセキュリティレベルによって代わってくるでしょう。私見ですが、まずはそれほど重要なデータを扱わないサービスからOpenIDへの対応が進み、これらの問題が認知・解決されていくにつれて、よりセキュリティレベルの高いサービスもOpenIDに対応していくのではないでしょうか。

連載のはじめにもお話ししたように、OpenIDを利用するためのインフラは既に整いつつあります。新しいサービスを始める場合のOpenID採用の検討に、この連載が少しでも役に立てば幸いです。