OpenIDが果たす役割を知る：デジタル・アイデンティティ技術最新動向（3）（1/2 ページ）

いまWebの世界では、さまざまなWebサービスが提供するプラットフォームと、サードパーティが提供するアプリケーションがAPIを中心に結び付き、一種の「APIエコノミー」を形成しています。この連載では、そこで重要な役割を果たす「デジタル・アイデンティティ」について理解を深めていきます。

» 2012年09月20日 18時00分公開

[ritou，OpenID Foundation Japan]

OAuth 2.0に続いて「OpenID」を振り返る

　はじめまして、ritouです。第1回、第2回でOAuth 2.0を紹介したNovさんと同じく、OpenID Foundation Japanのエバンジェリストとして活動しています。

　第3回と第4回ではOpenIDについて紹介します。本稿では、OpenIDがどのような課題を解決できるのかという基本的なところから振り返ります。

ユーザー認証の現状

　OpenIDプロトコルを説明するために、まずユーザー認証の現状から振り返ってみましょう。

　現在、多くのサービスがユーザー認証を実装しており、アカウント登録のために、メールアドレスやIDとパスワードをユーザーに設定させています。

　2012年2月に発表された野村総合研究所のアンケート結果によると、一般ユーザーが確実に記憶できるID／パスワードの組み合わせは平均3.15組、ID／パスワードを登録しているサービスの数は平均で19.4個だそうです（注1）。これは「多くのサービスがユーザー登録を必要としていること」、そして「たくさんのユーザーが同じパスワードを複数のサービスで使い回していること」を示しています。

注1：利用者登録する商品・サービスを選別する傾向が強まった生活者と顧客情報の鮮度維持を望む事業者

http://www.nri.co.jp/news/2012/120208.html

　あるサービスのパスワードを悪意のある第三者に突破されてアカウントを乗っ取られた場合、パスワードを使い回している他のサービスのアカウントにも被害が及ぶリスクがあります。複雑なパスワードを生成、管理できるソフトウェアを利用したり、メモとの併用で複数のパスワードを管理する方法などが提案されてはいますが、大多数のユーザーにとって複数パスワードの安全な管理は大きな課題であるといえるでしょう。

　一方、サービス側はどうでしょうか。

　今年になって、比較的規模の大きなサービスから数十万人のパスワードが漏えいしたというニュースがありました。サービスの入り口であるユーザー認証に必要なパスワードの漏えいは、サービス全体の信頼低下につながります。

　ユーザー認証を提供するサービスは、メールアドレスとパスワードのようないわゆる「クレデンシャル」を安全に管理するため、SQLインジェクション対策などさまざまなセキュリティ対策を講じる必要があります。

　また、提供するサービスの内容に対して認証手段が適切かどうかについても考慮が必要です。以前から、ネットバンキングなどセキュアなデータを扱うサービスでは、パスワードに加えてハードウェアトークンを用いた多要素認証が利用されてきました。最近では、他にも以下のようなサービスでも、高度な認証が必要だといわれています。

SNS：乗っ取ったアカウントの登録情報を悪用したり、友人に金銭を要求するメッセージを送ることでそれを信用した友人が送金してしまうリスクがある
メールサービス：パスワードリセットのメールを受けとられることで、他のサービスのアカウントも乗っ取られるリスクがある

　FacebookやGoogle、Yahoo!などのサービスは、多要素認証に加え、リスクベース認証を実装しています。端末や時刻、IPアドレスなど複数の情報から不正利用の可能性を判定し、必要に応じて追加認証を求めるように進化しています。すでにユーザー認証を実装しているサービスも、現在の認証手段が適切なものかどうかを定期的に見直す必要があるでしょう。

　このように、ユーザーのクレデンシャルを安全に管理し、適切な認証手段を提供することは簡単なことではありません。

　これでもあなたは自分でユーザー認証を実装しますか？ OpenIDは「クレデンシャル管理を自ら実装せず、ユーザーがいつも利用しているサービスに任せる」というアプローチをとり、リスクを回避する手段を提供します。

OpenIDプロトコルとは

　OpenIDとは「異なるWebサービス間でユーザーの認証情報を受け渡す方法」を定義したプロトコルです。

　OpenIDを紹介する記事の中ではしばしば、「OpenIDを発行」「あなたのOpenID URLを……」などといった説明があるため「OpenID＝ユーザー識別子」と認識している方も多いでしょう。本稿では用語による混乱を避けるため、「OpenID」という用語を、識別子ではなく認証情報を受け渡すプロコトルとして扱います。

　OAuthと同様に、OpenIDにも3者の登場人物（要素）がいます。ユーザーが「End User」、ユーザー認証を行う「OpenID Provider（OP）」、End Userの同意のもとにOPから認証結果を受け取る「Relying Party（RP）」の三者です。

図1　OpenIDの登場人物

　OpenIDプロトコルにおけるEnd Userの画面遷移は、OAuthのResource Ownerのそれと似ています。End UserはOP上で「RPにOP上の認証情報と属性情報を渡す」ことについて同意します。その後End UserはRPに戻され、RPはOPから受け取った認証情報を検証することでEnd Userが「何者か」を知ることができます。

　OpenID対応による登場人物三者それぞれのメリットは以下のとおりです。

OPは自社のユーザー認証を通して外部のサービスにログインできるため、アカウントの価値を高められる
RPはアカウント登録のハードルを下げることにより新規ユーザーを獲得しやすくなり、ユーザー認証機能を持たないことでリソースとコストをサービスそのものに集中できる
End Userは新たにパスワードを覚えることなくシームレスにRPを利用できる

　本稿執筆時点においてStableな仕様であるOpenID Authentication 2.0（OpenID 2.0）がOpenID Foundation（OIDF）により策定されたのは、2007年12月のことです（注2）。その後、次のような拡張仕様も策定されています。

OpenID Simple Registration Extension 1.0：ニックネームやメールアドレスなど、最低限のプロフィール情報を要求するための拡張仕様
OpenID Attribute Exchange 1.0：OP/RP間で属性情報を交換するための拡張仕様
OpenID Provider Authentication Policy Extension 1.0：RPによる認証ポリシー要求のための拡張仕様

注2：OpenIDファウンデーション・ジャパン翻訳・教育ワーキンググループにより一部の仕様が翻訳されています。詳細は以下の資料をご覧ください。

【関連リンク】OpenIDファウンデーション・ジャパン OpenID関連コンテンツのご紹介

http://www.openid.or.jp/modules/docs/contents/contents.html

　うまく拡張機能を組み合わせることで新規アカウント登録時のデータ補完ができたり、セキュアなユースケースにもOpenIDを利用できます。

　現在、OpenID 2.0は以下のようにさまざまな用途で利用されています。