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

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

OpenIDの各動作モード

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

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

●associateモード

【概要】

　ConsumerとIdPの間で、共通鍵の共有を行うためのモードです。

【使用するHTTPメソッド】

　POST

【動作フロー 】

　Consumer → IdP → Consumer

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

【注2】

smartモードやdumbモードはOpenID認証における、大まかな動作指針のような用語であって、openid.modeに適用されるassociate、checkid_immediate、checkid_setup、checkid_authenticationのような値ではありません。

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

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

●checkid_immediateモード

【概要】

　End Userの所有するClaimed IdentifierがVerified IdentifierであるかどうかをIdPへ即座に問い合わせるためのモードです。

【使用するHTTPメソッド】

　GET

【動作フロー 】

　Consumer → User-Agent → IdP → User-Agent → Consumer

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

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

• End UserのUser-Agentに、IdPのログインセッションがある
• End UserがIdPを通してConsumerに対して認証結果を通知することを継続的に許可している

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

●checkid_setupモード

【概要】

　End Userの所有するClaimed IdentifierがVerified IdentifierかどうかをIdPへ問い合わせるモードです。ただしcheckid_immediateモードと異なり、問い合わせの結果は即座には得られません。ConsumerはUser-Agentに認証結果をConsumerに共有させるかどうかを選択させるため、IdPのページにリダイレクトさせます。

【使用するHTTPメソッド】

　GET

【動作フロー 】

　Consumer → User-Agent → ［IdP → User-Agent］+ Consumer

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

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

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

●check_authenticationモード

【概要】

　End UserがIdPからリダイレクトされる際に渡される認証結果が正しいかどうか、IdPに問い合わせます。このモードはdumbモードのときのみ必要です。

【使用するHTTPメソッド】

　GET

【動作フロー 】

　Consumer → IdP → Consumer

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

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

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

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

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

• Claimed Identifierを入力するフォーム
• Claimed IdentifierからIdPのエンドポイントURLを抽出し、associateモードを必要ならば実行し、checkid_immediateまたはcheckid_setupモードを実行し、User-AgentをIdPへリダイレクトさせる機能
• 認証結果を伴いIdPからリダイレクトしてきたUser-Agentを受け入れ、認証結果を解析して、必要ならばcheckid_authenticationモードを実行する機能

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