RP にとっての OpenID の5つの課題
1ヶ月前から始まった gihyo.jp での OpenID の連載も、いよいよ最終回が公開された。ふぅ。
RP をどうやって作るかという情報は、まだ多くないみたいなので、この記事が少しでも役に立てば嬉しいなぁ。
という思いで書いてきた。 これまでは、 Rails でのサンプルアプリケーションの作り方など、プログラマの観点の記事だったけど、最後はちょっと視点を変えて設計・運用の視点からの課題を挙げてみたよ。
OpenIDにノレない５つの理由 - YAMDAS現更新履歴で紹介されている海外の記事で、「OpenIDでも結局1個のIDでは済まない」という問題点が挙げられているんだけど、これは僕も実感している。 まぁ、無理に1つにする必要はなくて、例えば今まで20あったIDが4つになりましたってだけでもメリットはあるけど、「ID の使い分け」が一般的に受け入れられるかどうか。
連載でとりあげた問題は以下の5つ。
1. URLをIDに使うことによる問題
インターネットで爆発的に増えるIDを整理するために登場したOpenIDですが，なぜ逆に煩雑になるように感じるのでしょうか。一つの理由は，「URLをIDとして使う」ことにあるのではないでしょうか。
URL を ID として使うことが OpenID の一番の特徴なんだけど、それゆえに OpenID の ID (User-Claimed Identifier) がユーザフレンドリーじゃないよね、と。 そのための xri とか i-name なんだろうけど、そのためにもう1つ新しいインフラが必要だからなぁ。
2. OpenID Providerのサービス停止に備える
さらに大きいのは，OPがサービスを一時的・恒久的に停止した場合に，RPへもログインできなくなるという問題です。
シングルサインオンサービスとしては、昔から考えられる問題。 OpenID の場合は OP が分散しているので、はてな認証API や TypeKey などの独自の認証サービスに依存するよりはリスクが低いかもしれない。 この問題をもっと深く考えると ID のライフサイクルの話になってくるんだけど、こっちは openid-ja での議論が参考になる。
3. 利用者がOpenIDアカウントを忘れた場合への対応
通常のパスワード認証で最も多い問い合わせは，利用者が自分のIDやパスワードを忘れることでしょう。同じようにOpenIDでも，利用者がOpenIDアカウント名を忘れる可能性があります。
今の時点で OpenID を使う人はそれなりにリテラシーがあるけど、もっと普及したらこういう問題もでてくると思うな。
4. WebAPIを提供する場合の認証をどうするか
WebAPI経由で利用者の情報を操作する場合にも認証が必要となります。パスワード認証の場合は，WebAPIにBasic認証などを適用することが可能ですが，OpenID認証の場合はそうはいきません。
OpenID と認証 API は相性が悪いよねという話。 そのための OAuth なんだけど、そういえば Twitter の OAuth 対応はどうなったんだろう。 twitterfeed.com のような Twitter API を使うサービスでも、やっぱり Twitter の ID とパスワードを要求してくる。 Twitter に使う程度のパスワードなら、他人に教えても問題ないって考えが多いのかな。
5. 信頼できないOPを利用することによる問題
OpenIDの特徴は，OPという認証サーバが分散していることです。インターネット上のサーバであれば，誰でもOPになることができるため，OPのセキュリティレベルにはばらつきがあります。
これはOpenIDをとりまくセキュリティ上の脅威とその対策 - @ITでも山口さんが触れられている話。
まとめ
いろいろ挙げたけど、徐々にこういう問題はクリアになっていくとは思ってる。 OpenID というとこれまでは技術的な話が多かったけど、今年からはこういう運用の話が増えていくんじゃないかな。 それよりも僕は「OpenID を使おうと思った人がすぐに使える」状態になっていることを評価してる。 インフラの整備は時間がかかるものだけど、 OpenID はその第一段階をクリアしているんだからね。