仕様から学ぶOpenIDのキホン：OpenIDの仕様と技術（1）（1/3 ページ）

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

» 2007年07月06日 00時00分公開

[山口徹，サイボウズ・ラボ株式会社]

OpenIDってなんだろう？

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

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

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

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

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

などが挙げられます。

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

【注1】

正しくいえば同一のアカウントを利用することは可能ですが、認証済みのIDに対して、認可を安易に行うかどうかは別問題です。

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

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

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

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

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

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

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

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