share facebook facebook twitter menu hatena pocket slack

2012.03.29 THU

OpenID Vol1.OpenIDの概要

櫛田 草平

WRITTEN BY 櫛田 草平

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の整合性についてもう少し踏み込んでみたいと思います。

櫛田 草平

櫛田 草平

cloudpackで運用、保守、構築、夜間対応を担当しており、日々様々な課題に対応していますのでこの経験を記事にしていけたらと思います。 櫛田 草平