第2回：PHPで作ろうConsumer (3/3)

Consumerの仕組みについてもう少し詳しくみてみよう

さて、駆け足でPHP-OpenIDのConsumerのサンプルを紹介しましたが、その中で出た用語や意味を詳しく解説しておきましょう。

OpenIDは現在、バージョン1.1とバージョン2.0の2つの仕様が存在しています。バージョン2.0の最終仕様は2007年12月5日に公開されたばかりで、利用できる暗号化方法の選択肢の拡張をはじめ、いくつかの手順やパラメータの名前、用語などが変更されています。

例えば本記事では「Consumer」「IdP（Identity Provider）」という言葉を使っていますが、バージョン2では「Relying Party（RP）」および「OpenID Provider（OP）」に変更されました。認証対象となるルートURLである「openid.trust_root」は「openid.realm」に変更になっています。

ただし、ConsumerやIdPという言葉は、PHP-OpenIDのライブラリの中でも使われているため、本記事ではバージョン1.1での呼び方に統一しています。なお、バージョン2のドキュメントを読む際には、上記の新しい呼び方で書かれているので、注意が必要です。

バージョン2はまだ公開されたばかりで、それを実装しているIdP（OP）もまだほとんどありません。しかし今後は、そうしたIdPも増えてくるでしょう。ちなみにOpenID-PHPは、バージョン1.1と2.0のどちらも利用できるようになっています。今回はバーション2について詳しくは述べませんが、興味のある方はOpenIDの公式サイト（http://openid.net/）の仕様書をご覧ください。

OpenIDでは、1度の認証の間にエンドユーザとConsumer、IdPの3つのコンピュータの間で、何回ものやり取りが行われます。すべてのやり取りはHTTPプロトコルに則り、POSTもしくはGETリクエストによって行われます。例えばクエリパラメータやPOSTの場合は、データの名前と実際のデータの内容というペアで、メッセージボディに格納されています。名前はすべて「openid.」ではじまります。

サンプルとして、IdPへConsumerからリダイレクトされた場合のURLをみてみます（リスト1）。

リスト1：IdPへConsumerからリダイレクトされた場合のURL

http://www.openid.ne.jp/user/auth?openid.assoc_handle=%7BHMAC-SHA1%
7D%7B475c7a5c%7D%7BOJ2v4w%3D%3D%7D&openid.identity=http%3A%2F%
2Fnanzou.openid.ne.jp%
2F&openid.mode=checkid_setup&openid.return_to=http%3A%2F%
2Fwww.takaaki.info%3A80%2Fopenid_consumer%2Ffinish_auth.php%
3Fjanrain_nonce%3D2007-12-11T18%253A52%253A30ZbtXZ1b%
26openid1_claimed_id%3Dhttp%253A%252F%252Fnanzou.openid.ne.jp%
252F&openid.sreg.optional=fullname%
2Cemail&openid.sreg.required=nickname&openid.trust_root=http%3A%2F%
2Fwww.takaaki.info%3A80%2Fopenid_consumer%2F

図3：アクセス画面の表示パターン
（画像をクリックすると別ウィンドウに拡大図を表示します）

データ量が多くわかり辛いですが、「openid.assoc_handle」や「openid.identity」「openid.return_to」「openid.trust_root」などのパラメータがURLに含まれているのがわかるでしょう。openid.identityは、エンドユーザーが送ってきたIdentifierのURLが入っています。openid.assoc_handleは「アソシエーションハンドル」です。これはすでに解説しましたが、ConsumerとIdPの間でのやり取りの際にリレーの「たすき」のように必ずつけて送られるデータです。

また、openid.modeというデータもあり、上記の例ではcheckid_setupというデータが入っています。これは「checkid_setup」というモードでIdPの認証処理を行う、ということを指定したものです。これは、今回のサンプルのように、リダイレクトなどを用いてIdPのWebサイトに誘導され、そこで認証処理が行われる方法です。さらに「checkid_immediate」というモードでは、JavaScriptなどを使って画面遷移せずに認証を終えることができます。

通常IdPは、WebブラウザからのアクセスをCookieなどを使用して状態を判別する、独自のログインシステムを備えています。渡されたIdentifier URLと、ログインしているユーザが一致すれば、「読み取りを許可しますか？」といったメッセージを表示します。しかしログインしてなければ、ログインを促し、ユーザが違えばエラーやユーザ名切り替え画面を表示します。

このあたりの挙動はIdPに一任されています。例えばユーザ情報が一致すれば特に確認画面を表示せず、「認証成功」と見なしてConsumerにリダイレクトをしてしまうIdPも存在します。

さて、次回はIdPのより詳しい仕組みや実装方法について、実際にサンプルを使って解説します。