第3回 Consumerの実装を知り、OpenIDを使ってみよう：OpenIDの仕様と技術（3）（2/3 ページ）

OpenIDの各動作モード

　OpenIDは認証手続きの各フェイズで、openid.modeというパラメータの値に適切なモード値を設定することによって、異なる動作をします。前回は簡単なフローを図解しましたが、ここではさらに深く知るために詳しく説明します。フロー図を見ながら読み進んでください。

図1　smartモード時の認証フロー

●associateモード

　associateモードは、ConsumerとIdP間で共通鍵を共有するために行う手続きです。なぜ、共通鍵をConsumerとIdPで共有しなければならないかは別の機会で説明しますが、前回の内容で少し触れたsmartモードという方式で認証手続きを行う際に必要なモードとなります【注2】。

　associationを行わなかったり、不正な結果が返ってくるなどしてassociateモードが失敗した場合は、dumbモードでの認証フローに移行します。現段階ではConsumerとIdPの間で事前に信頼関係を結んでおくとだけ理解しておいてください。

　このモードは図1の中の「（3）キャッシュが無い場合は共通鍵の共有処理」フェイズで行う処理です。 ここでいうキャッシュとは、Perlの実装ではNet::OpenID::Consumerのcacheメソッドで扱うCacheオブジェクトそのものを指し、associateが成功した場合は、一定期間Consumer側でassociationをキャッシュとして保持することになります。

●checkid_immediateモード

　よりかみ砕いた説明をするならば、このモードはAjaxスタイルで用いることを想定しています。immediateは、「即座に問い合わせてレスポンスを得る」という意味合いです。

　認証処理がEnd Userによる認証情報の入力がないまま返ってくるケースとしては、

という、2つの条件が満たされている場合が挙げられます。

●checkid_setupモード

　checkid_immediateモードとは対を成すモードです。

　こちらはIdP側のページに遷移し、そのページで自分の認証結果と要求されていた場合の属性情報をどのように通知するかを選択する画面が表示されます。

　このページで許可した場合は認証が正常に完了しますが、キャンセルした場合はその旨がConsumerに返されます。

●check_authenticationモード

　dumbモードでは事前にassociateモードによる、ConsumerとIdP間での信頼関係が成り立っていません。従ってIdPからのレスポンスがEnd UserのUser-Agentのリダイレクト経由で渡されるので、そのクエリパラメータをそのまま信頼するわけにはいきません。別途シグネチャを利用して確認する手続きを行う必要があります。それを行うのがこのモードです。

　この手続きがどういったときに、なぜ必要なのかはOpenIDのセキュリティモデルに関してまとめて別の機会で扱いたいと思います。

Net::OpenID::Consumerを使った手続きの流れ

　さて、ここまで解説した内容を振り返りつつ、どのように実装していけばよいかを考えましょう。

　まず、必要となる機能を列挙していきましょう。大きく分けて以下の3つの機能が必要になります。

　これらの機能を、実際にCatalystというPerlで最も有名なフレームワークを用いて実装していきます。