Tweet

第1回 仕様から学ぶOpenIDのキホン

にわかに注目を集めている、URLをIDとして利用する認証プロトコル、OpenID。本連載ではこのプロトコルの仕組みを技術的に解説するとともに、OpenIDが今後どのように活用されていくのかを紹介する（編集部）

　OpenIDってなんだろう？

　現在、国内外でにわかに注目されつつあるOpenIDという仕組みを聞いたことがあるでしょうか？ これはユーザー中心の分散ID認証システムですが、まだ日本での普及は進んでいない状況です。

　これにはいくつか原因が挙げられるでしょうが、筆者はOpenIDが正しく理解されていないことが原因だと考えます。

　本連載ではOpenIDの現行仕様、およびその拡張仕様とともに、実装を例に取りつつOpenIDとは何かということを明らかにしていきます。最終的にはOpenIDが切り開く未来を見るため、現在策定中の次期仕様についても触れていきたいと思います。

　広がりつつあるブラウザベースの認証API

　Web上での認証APIサービスにはすでにいくつかのサービスが存在します。代表的なものとしては、

• Flickr Authentication API
• Google Account Authentication
• Yahoo Browser-Based Authentication
• TypeKey API
• livedoor Auth
• はてな認証API
• JugemKey 認証API

などが挙げられます。

　これらのサービスを利用してシステムを作ると、シングル・サインオン（SSO）に近い仕組みを導入することができます【注1】。

図1　シングル･サインオンの仕組み

　これらのサービスにほぼ共通していえることがいくつかあります。その中でも特筆すべき事柄は2つで、1つは特定のサービスプロバイダのアカウントに依存していること、もう1つがWebブラウザをベースとした認証システムであるということです。

　「認証（Authentication）」と「認可（Authorize）」って何が違う？

　ID管理の中で良く聞く「認証（Authentication）」と「認可（Authorize）」は明らかに異なります。

　OpenIDが認証の仕組みと、その認証されたIDを受け入れるサービス側がどのようなポリシーで認可を行うかという問題に対して、OpenIDが持つ潜在的な問題点を明らかにして行くために、ここで言葉を定義しておきましょう。

• 認証（Authentication）
  そのユーザーが自分の物であると主張するIDに対して、そのIDが確かにそのユーザーの物であるということを保証すること
  
  
• 認可（Authorize）
  認証されたIDを受け入れ、サービスに対して適切な権限を与えること

　一般的なWebベースの認証サービスは、特定の認証プロバイダがユーザーのIDの認証を担当します。サービス側から見れば、特定の認証プロバイダが信頼に足るならば、その認証プロバイダが認証したユーザーのIDを認可する上でそれほどの問題はありませんが、OpenIDは分散認証システムであり、この認証プロバイダが複数存在します。

　この認証プロバイダは限定されたベンダが行っているとは限らないので、通常の認証局と同等に考えるのは妥当ではありません。

図2　認証と認可の違い

　この細かいニュアンスの違いはOpenIDにとっては大きな意味を持ってきます。

1/3

Index
仕様から学ぶOpenIDのキホン
	Page1 OpenIDってなんだろう？ 広がりつつあるブラウザベースの認証API 「認証（Authentication）」と「認可（Authorize）」って何が違う？
	Page2 特定のベンダに依存するメリット・デメリット OpenIDの現行仕様 OpenIDの概観を学ぼう
	Page3 保存版・OpenID1.1の用語集

OpenIDの仕様と技術 連載インデックス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード