OpenIDとセキュリティ――経路の安全性をどう担保するか：ZIGOROuのOpenID Short Clinic

OpenIDにかんするさまざまな疑問を解消していく本連載。今回は、OpenIDではどのような流れで認証手続きが行われているのかを解説する。

[山口徹，ITmedia]

OpenIDについて少しづつ理解してきたつもりなのですが、OpenIDを使うに当たってセキュリティ上の課題や問題などについてまだ理解が十分でなく、少し心配です。OpenIDのセキュリティについてその仕組みのほか、推奨される対策などがあれば教えてください。

この話題はなかなか難しい話で、少し説明が長くなりそうなので複数回にわたって取り扱いたいと思います。多少難しい解説でも構わない方は、わたしが以前＠ITで書いたOpenID のセキュリティに関する記事も参考にして参照ください。

OpenIDのセキュリティを語る上で最も重要な点

　まずOpenID認証プロトコルで定義されているセキュリティに関連する登場人物をあらためて復習しましょう。それぞれの用語の理解が十分でないとお感じの場合は、過去の「ZIGOROuのOpenID Short Clinic」をさっと読んでおくとよいでしょう。

• End User（利用者）
• User-Agent（利用者のブラウザ）
• Relying Party（認証依存サイト：RP）
• OpenID Provider（OpenID認証プロバイダー：OP）

　OpenID認証プロトコルでは、認証にまつわるメッセージのやり取りを常にOP EndPoint URLと呼ばれるOP上のエンドポイントURLに対して行いますが、その手法には「Direct Communication」「Indirect Communication」という2つのパターンがあります。

　Direct CommunicationとはRPとOP間で文字通り“直接”行われるメッセージのやり取りです。

Direct Communication

　一方、Indirect Communicationとは、まずRPがUser-Agentに対してOP EndPoint URLへのLocationヘッダを設定することでUser-AgentをOPに遷移させます。ここまでがリクエストです。

　このリクエストに対してOPはユーザーの認証結果を返すのですが、今度はOPがUser-Agentに対してRPへのリダイレクト要求を行い、User-AgentをRPに遷移させることによって返されます。なお、どこにリダイレクトさせるかは認証リクエスト時にopenid.return_toパラメータで指定しておく必要があります。

Indirect Communication

　ここでは、OPとRPが直接リクエスト・レスポンスの受け渡しを行うのがDirect Communication、ユーザーのWebブラウザを介してリクエスト・レスポンスの受け渡しを行うのがIndirect Communicationであると覚えておけばよいでしょう。なぜ2つのパターンがあるのかについては、OpenIDの動作モードやセキュリティモデルによるところが大きいのですが、これは別の機会で解説したいと思います。

　少なくとも、OpenIDでは認証にまつわるメッセージのやり取りをする経路が幾つか存在していることはご理解いただけると思います。そして、この経路間でのプロトコルメッセージのやり取りこそが OpenIDのセキュリティに関するトピックのほぼすべてであるといえます。

まずはSSLを使いましょう

　ありがちな結論ではありますが、まずはOP EndPoint URLには信頼あるauthorityによるCertification（証明書）があるSSLを用いるのが最も簡単で信頼性を高める方法となります。

　SSLを用いるだけでDNS解決などの不正な改ざんによる攻撃手法を防止できます。またUser-Agentを介したIndirect Communicationは経路が多いですが、その間の通信もメッセージがSSLにより暗号化されますので、より安全になります。

著者：山口　徹（やまぐち とおる）

サイボウズ・ラボで研究開発にいそしむPerlハッカー。Perlを中心とした開発のノウハウやネタをShibuya Perl Mongersのイベントで発表するなど講演活動も行う。最近ではOpenIDの実装方法や考察などをブログ「Yet Another Hackadelic」などで書き連ねている。