OpenIDに関わる機会があったのでOpenIDの概要を紹介します。
普及しそうでしていないOpenIDでありますが、docomo、au、SoftBank各キャリアのスマートフォンの
公式コンテンツを構築する必要が発生し、各社が端末認証でOpenIDを採用している事から、
このサービスに触れる事になりました。

各社独自の拡張ルールはありますが、ベースとしてはOpenID Authentication 2.0に準拠しています。

まずOpenIDとは何かについてです。
以下は他サイトからの抜粋となります。

OpenIDとは、世界中のOpenID対応サイトで共通して利用できるURL形式のIDのことです。
OpenID対応サイトで利用すれば、新たにアカウントを作成したり、
ログインするために別々のIDやパスワードを入力する必要がなくなります。

しかし、現実には携帯3社に焦点を当ててみても、それぞれOpenIDを作成したり、
それぞれの受け皿構築をしなければいけないので、このような仕様が敷居を高くしている要因なのだと思います。
docomo用アカウントでスマートフォンからでもPCからでもdocomo用サイトに限ってはログインできるという
汎用性はありますが。

本ブログではOpenIDの概要という事で、OpenID対応サイトに絡む開発機会に直面した際に
必ず出てくるであろう言葉の説明や認証の流れを説明します。

  • OP・・・あるWebサイトがユーザ認証機能を有し、その認証にOpenIDを採用しているサイト。
    OpenIDプロバイダ。
  • RP・・・OpenID対応の他のWebサイト（relying party：RP）

私の開発で例えるならば、OPはdocomo、au、SoftBank。RPは私が認証プログラムを構築している公式サイトに
なります。
RPの立場として、認証ロジックの大まかな流れは以下の通りになります。

  1. OP指定の認証URLにアクセス。その際、realmとreturn_toというパラメータを渡す。
  2. リクエストを受け取ったOPは、受け取ったrealmとreturn_toの正当性チェックを行い、ログイン画面を表示
  3. アクセスユーザがIDとパスワードを入力。正しければOPはreturn_toで指定されたURLにレスポンスを返す

概要となりますが、理屈としてはこのような形になります。
realmとreturn_toという語句が出てきましたが、以下はその説明です。

  • return_to・・・OPが認証後にレスポンスを返すURL。RPはここに認証画面などを用意する。
  • realm・・・ここで指定された文字列（実質httpで始まる）が、return_toに完全一致で含まれていなければ
    ならない。

以下は例になります。
return_toが『https://www.hoge.jp/return.php』として、realmは『https://www.hoge.jp/』もしくは
『https://*.hoge.jp』でなければいけません。
『https://fuga.jp/』となるとreturn_toと一致しない為、OPから拒否されます。

詳しい方でしたら『自分でreturn_toとrealmを渡すんだから、文字列一致に何の意味があるの？』と考えると
思います。
その通りで、このままでは自作自演のチェックになります。

実は、OPの傘下に入る為のRPになるには、事前にOPに対して申請が必要なのですが
その申請内容のひとつに『このrealmを使います』ということを通達する必要があります。
これによりOP側は、申請されたドメイン・ホスト名からのアクセスか、申請に則したパラメータが渡っているかを
チェックして認証画面を提供します。

次回はreturn_toとrealmの整合性についてもう少し踏み込んでみたいと思います。