OpenIDの認証については、この段階で完了していることになる。ただしopenid.netのwikiにログインするのが今回がはじめてという場合は、さらに幾つかのステップを踏んでからでないと同wikiのユーザーアカウントは設定できない。それというのも、OpenIDで置き換えられるのはあくまでサインオンのプロセスだけであって、ユーザー名の表示や接続情報など、ユーザーアカウント管理におけるそのほかの情報の処理については、個々のサイトの責任とされているからである。また過去にユーザーアカウントを作成しておいたサイトが新規にOpenID機能をサポートしたという場合も、サインオン手順を除くユーザーアカウント関連の変更は原則的に発生しないはずであるが、最終的にどうなるかは当該サイトを管理する人間の裁量次第というのが本当のところである。いずれにせよ重要なポイントとしては、OpenIDで置き換えられるのはサインオンのステップだけである、という点を覚えておけばいいだろう。
現実問題として、OpenID用URLをユーザー名に使用できるようにしたOpenID対応サイトは多数存在しているようであり、その普及が進んでいる理由としては、ユーザーに記憶を強いる情報を1つ削減できること、および、ほぼ確実にユニークな識別値を利用できるという、極めて明白なメリットを挙げることができる。もちろんサイトによっては、ユーザー名としてのOpenID用URLの使用を強制しているところも存在するであろうが、そのような場合ユーザーはyourname.someOpenIDprovider.comといった無機質極まる文字列をハンドル名代わりに使わなければならない羽目になる。
ただし幸いなことに、委託(delegation)と呼ばれるプロセスを用いることで、任意のURLをOpenIDとして用いることができるシステムになっている。そのために必要な手順は、OpenID用 URLとして利用したいページに特殊なHTMLタグを登録しておき、そこから本来のsomeOpenIDprovider.comサイトをポイントさせておくことである。より具体的に説明すると、先に説明したタグ<link rel="openid.server" href="http://someOpenIDprovider.com/server" />および“正式”な認証URLをポイントする<link rel="openid.delegate" href="http://yourname.someOpenIDprovider.com/" />が必要であり、これらはいずれもドキュメントのHEADセクションに登録しておくことになる。
以上、可能な限りかいつまんでOpenIDを用いたログインプロセスの概要を説明してみた。より詳しい技術的な情報について知りたければ、各種のレベルに応じた参考資料へのリンクがopenid.netのwikiに用意されているので、そちらを参照して頂きたい。実際ここで述べたのは、ハンドシェイクの基本シーケンスでしかない。例えばOpenIDに対応した一般公開型サイトを運用しようと思えば、固定接続やステートフルセッションなど、重要なさまざまな概念が関係してくる。
Copyright © 2010 OSDN Corporation, All Rights Reserved.