はじめに

Yahoo!やYahoo!JapanがOpenIDサービスの提供を始めたり，MixiがOpenID対応を表明したりと，最近OpenIDについてのニュースを耳にするようになりました。 ところが，OpenIDという言葉は知っていても，実際に使ったことのある方はまだほとんどいないのではないでしょうか。

OpenIDによる認証を提供するサービスが増え，インターネット上でアカウントを持つ人の多くがOpenIDを利用できるようになっています。 さらにOpenIDを扱うPerlやRubyなどのライブラリも充実してきています。 このように，OpenIDを使うための環境は整ってきていると言えます。 そこで，本連載では実際にOpenIDを使ってみながら，その仕組みについて解説していきます。 同時に，仕様では見えてこないOpenIDを使う上でのコツも，説明していければと思います。

OpenIDとは

OpenIDとは，いったい何でしょうか。 OpenIDの公式サイトには，以下のように書かれています。

OpenID is a free and easy way to use a single digital identity across the Internet.

「1つのIDをインターネット上で無料かつ簡単に使うための仕組み」ということですが，端的に言うとYahoo!やはてな等のアカウントを使って，他のサイトにログインすることができるようになります。 「IDを1つにする」という考え方は以前からありましたが，OpenIDはそれまでの考え方と何が違うのでしょうか。

大きな違いは認証サービスが分散していることです。

集中型の認証APIと分散型のOpenID

WebではBlogやWebメールなどの，様々なサービスが提供されています。 これらのサービスを使うためには，それぞれに登録したIDとパスワードを使って認証していることと思います。 ですが，利用するサービスが増えると，サービスごとのユーザ登録が面倒になったり，IDとパスワードが増えて覚えきれなくなるという問題が発生します。

この手の問題は古くから存在しており，イントラネットなどの利用者が限定される環境では，WindowsのActive Directoryなどのようにディレクトリを用いて利用者の情報を集中的に管理する方法が採用されています。

Webでも，次に挙げるように，いわゆる「認証API」と呼ばれるユーザ認証の仕組みが各社から提供されています。

• TypeKey認証
• はてな認証API
• livedoor Auth
• JugemKey認証API

これらは，それぞれのサービス提供者のユーザIDで，他のサイトへログインするための仕組みです。 しかし，不特定多数の利用者やサービス提供者が存在するWebでは，認証というサービスの基盤に関わる機能を特定のサービスに任せることへの心理的な抵抗感があり，広く普及するところまでは至っていません。 かといって，複数の認証APIに対応するためには，それぞれの認証APIとのインタフェースを作り込む必要があり，そのためのコストがかかってしまいます。 そこで，特定の認証サービスに依存しない仕組みとして，OpenIDが着目されるようになってきました。

従来の集中型の認証APIと異なり，OpenIDでは複数の認証サービスが存在します。 OpenIDに対応した認証サービスを提供しているところであれば，どの認証サービスでも使用できます。 複数の認証サービスが混在できるように，OpenIDではユーザIDとしてURLを用います。 例えば，筆者のはてなでのOpenIDアカウント名は以下のようになります。

http://www.hatena.ne.jp/kmachu/

ただし，すべての認証サービスですべてのOpenID対応サイトにログインできるとは限りません。 対応サイトによっては，受け入れる認証サービスを制限しているところもあります。

また，OpenIDはユーザを認証するための仕組みを提供しますが，認証されたユーザが信頼できるかどうかは別問題です。 特に，誰でも認証サービスを提供できるという仕組みであることから，認証サービスによって信頼性はまちまちです。 ユーザ登録時にCAPTCHAやメールの到達確認を行うことでbotやスパマーの登録を防いでいる認証サービスもあるでしょうし，誰でもすぐに登録できてしまう認証サービスもあるかもしれません。 今のところ，どの認証サービスを信用するかは，利用者やOpenID認証を受け入れるサイト次第と言えます。

OpenIDの主な用語

最低限覚えておきたい，OpenIDで登場する用語は次のとおりです。より詳しくは，OpenIDの仕様書や@ITでのOpenIDの仕様と技術などを参照してください。

OP（OpenID Provider）

OpenIDによる認証サービスの提供者です。

RP（Relying Party）

OpenIDによる認証を受け入れるサイトです。

Claimed Identifier

利用者のOpenIDアカウント名。本連載では便宜的に「OpenIDアカウント」と呼びます。

OpenIDでの認証の仕組み

認証サービス（OP）のOpenIDアカウントで別のサイト（RP）へログインするときの流れについて説明します。

1. 利用者はRPにアクセスし，自身のOpenIDアカウント（Claimed Identifier）を入力します。
   ※後述しますが，利用者はClaimed Identifierの代わりにOPのURL（OP Endpoint）を入力することもあります。これらを総称して，ユーザ提供識別子（User-Supplied Identifier）と呼びます。
2. RPは入力されたOpenIDアカウントを元に，OPを探します。
3. RPはOPとの間で，共通鍵を交換します。この鍵はOpenIDメッセージの改ざん防止に使われます。
4. RPは利用者をOPへとリダイレクトし，利用者の認証を要求します。
5. 利用者はOPにログインしていなければ，IDとパスワードでOPへログインします。OPはOpenIDアカウント名をRPへ通知していいかどうかを利用者に確認します。
6. 利用者がアカウントの通知に同意すれば，OPは利用者をRPへとリダイレクトして，認証結果をRPへと通知します。
7. RPは受け取った認証結果に含まれるClaimed Identifierで，利用者を認証します。

流れだけを見るとなんだか複雑そうに見えるので，実際のサービスで試してみることにしましょう。