最も基本的なレベルでの説明をすると、個々のユーザに与えられる認証用のOpenIDとは重複のないユニークなURL値ということになる。具体的には、個々のユーザレベルで管理可能なURL（各自のWebページやブログのアドレスなど）ないしは、OpenIDプロバイダなどのサードパーティ系サービスから各ユーザに提供されるURLがこれに該当する。この意味において、サイトの認証システムでOpenIDを用いた場合と、その代わりに通常の電子メールアドレスを識別子として用いた場合とでは、何ら変わる点がないことになる。いずれの情報も個々のユーザに関するユニークな値であり、それなりの検証性を備えているからだ。しかしながらOpenIDには、その情報をネット上で公開したとしてもスパム攻撃に利用される心配をしないで済むという大きなメリットが存在するのである。
OpenID対応サイトにサインインする際には、サインインするユーザ、OpenID用URLをホストする何らかのサイト、サインイン先のサイト、認証サーバ（サインイン先のサイトとユーザとの認証を取り持つ）という、4つの要素が関与する。なおOpenIDの正式な用語として、サインイン先のサイトのことは“コンシューマ”（consumer）と呼ばれている。
OpenIDは完全な分散型システムとして機能するよう設計されており、先に挙げた4つの要素を3つに減らすためのオプションもいくつか用意されている。その1つの方式は、ユーザが独自のWebサーバを用意し、各自のOpenID用URLのホストおよび認証サーバとして、そうしたサイトを運用することである。その他の方法としては、一般のOpenIDプロバイダの1つで自分のアカウントを作成しておき、各自のOpenID用URLのホストおよび認証サーバの役割も、そうしたプロバイダで担ってもらうという方式も存在する。
初心者にとっては、後者のオプションの方が簡単だろう。所定の手続きをして必要な情報を登録すれば、今すぐにでもOpenIDを利用できるからだ。利用可能なOpenIDプロバイダについてはopenid.netのwikiにリストアップされているので、適当なプロバイダを選択してアカウントを作成すればいい。その際には電子メールを用いた認証を要求されるかもしれないが、いずれにせよ必要な手続きが完了すれば、正式なOpenID用URL（たいていはhttp://yourname.someOpenIDprovider.comといった形式）の所有者となれるので、次に行うべきは、具体的にどのようなプロセスでログインするのかを実地に試してみることである。
OpenID関連のサイトを探せば様々なドキュメントが用意されているが、ログインのプロセスといった類の操作は、自分で実際に試してみるのがベストなはずだ。例えば「protocol spec」という仰々しい名称の付けられた高度な内容のドキュメントも存在するが、エンドユーザにとってはそのような情報よりも、実際にOpenIDを用いたコンシューマサイトにおける具体的なログインのプロセスや、必要な設定作業やその後の管理に関する手順が従来型のアカウントとどのように違うかの方が重要なはずであり、そうしたものは実地に試してみないと分からないものである。
OpenIDを用いたログインの流れ
ここではhttp://yourname.someOpenIDprovider.comという架空のURLを持つページについて考えてみよう。たいていの場合こうしたページは非常にシンプルな構成を取っており、「ここはyournameというユーザに関する認証ページです」といった内容のメッセージと、OpenIDについてのFAQへのリンクが張られている程度である。肝心なのはそのHTMLソースであって、<link rel="openid.server" href="http://someOpenIDprovider.com/server" />という形式で、ヘッダ部にキータグが埋め込まれている。このタグからは、コンシューマサイトからの問い合わせに対して、当該ユーザの認証を行うための接続先を指定する情報が提供されるのである。細かい説明はここまでにするとして、後は適当なサイトを選んで実際にログインしてみることにしよう。
OpenIDに対応したサイトを見分けるのは簡単である。そうしたサイトのログインフォームでは、オレンジ色の縦棒と灰色の丸い矢印をあしらったOpenIDのロゴが表示されているはずであり、すでにお馴染みとなったRSSマークと同様の感覚で探すことができるようになっている。今は単にログイン手順を確認することが目的なので、適当なOpenID対応コンシューマのサイトを選択してログインすればいい。ここではopenid.netのwikiを使うことにしよう。このwikiではすべてのページからログインページにアクセスできるようになっており、そのページにはOpenIDの入力用フィールドが1つ存在するだけである。OpenIDプロバイダから取得しておいた各自のOpenID用URLをこのフィールドに入力して、ログインボタンをクリックすれば、後は必要な処理が自動的に実行される。次に、それらがどのような処理であるかを見ていこう。
openid.netのwikiの場合、入力されたURLが有効なものであるかの確認および、当該ページのデータの取得が行われてから、先のrel="openid.server"のタグの検索が実行される。その次に来るのが、このタグに指定されているサーバにアクセスして行われる、入力されたOpenID用URLに関する照合作業である。こうしてアクセスされたサーバ側としては、ログインを試みたユーザが登録された当人であるかの認証、当該ユーザのログイン先と問い合わせをしてきたopenid.netのwikiとが一致しているかの確認、およびトランザクションやユーザ識別に関する情報の漏洩防止といった処理に責任を負わなければならない。
そのためsomeOpenIDprovider.comサーバは、ユーザの本人確認を行うため、当該ユーザに対してsomeOpenIDprovider.comに直接ログインするよう求めるか、あるいはクッキーをチェックすることで現在のブラウザセッションにおいて以前に同様の認証が行われていないかを検証する。その次に行う、ユーザの指定したログイン先と実際のログイン先とが一致していることを確認する処理では、ユーザに対してopenid.netのwikiの参照ページに関する質問を実行する。
このようにしてユーザの本人確認が正常に終了し、ログイン先がopenid.netのwikiで間違いないことが確認されると、このサーバは当該ユーザを参照元のwiki（実際には“ログインは正常に終了しました”旨を示すページ）にリダイレクトするのと並行して、それとは独立した形で確認終了のメッセージを同wikiに直接送信する。ユーザのリダイレクトおよび確認終了のメッセージには、どちらもワンタイムセッションキーと暗号署名が付けられているが、これらは別々に送信されるため、wiki側で両者を比較することによりトランザクション全体が正当なものであることを確認できるようになっている。
OpenIDに関するその他の付帯事項
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に対応した一般公開型サイトを運用しようと思えば、固定接続やステートフルセッションなど、重要な様々な概念が関係してくる。
OpenIDでは行えないこと
一般公開型のWebフォーラムの運用については多種多様な問題が付随するものであるが、そのほとんどはOpenIDを導入したとしても解決されない性質のものである。例えば、ブログにおけるコメントスパムなどもその1つだ。仮にブログのログインフォームをOpenID化したとしても、スパマやスパムボットが多数のOpenIDアカウントを準備して山のようなコメントスパムを投稿してくれば、そうした行為を阻止することはできない。コメントに必要なアカウント用のメールアドレスを偽造する代わりに、聞いたこともないOpenIDサーバから取得されたOpenIDが使われるだけのことである。つまりスパムの防止についても、電子メールリレーの場合と同様、信頼していいOpenIDサーバとブラックリストに登録すべきOpenIDサーバとを人間の手で個別に指定しなければならないのだ。
もう1つ別の例として、何処かよそのブログで自分を中傷するコメントを偶然見つけ、その投稿者として知人の1人の署名が添えられていたというケースに遭遇したとしよう。現行のシステムにおいて、それが本当にその知人本人が投稿したコメントであるかを知る術はないが、仮にそのサイトにOpenID用のログインシステムが追加されたところで、そうした点は何も変わらないのだ。つまり、メッセージの真偽確認とOpenIDとは何の関係もないのである。結局のところ、こうしたケースについてはサイトそのものが捏造された可能性も否定できないので、メッセージの真偽確認をしようと思えば、OpenPGPなどの暗号署名機能を利用するしかない。
OpenIDで何が行えるかを知る人間が増えるほど、その普及は促進されるはずであり、現状で最も必要とされているのはそうした啓蒙活動なのである。今日の文明社会を取り巻く環境では、ソフトウェアやハードウェアを購入するごとに、各メーカのユーザフォーラムを利用するためのアカウントを新規に作成しなければ、製品の使用法を問い合わせることすらできないのが現実である。OpenIDが導入されたとしても、こうしたメーカのフォーラムにサインアップする必要性が消え去る訳ではないが、OpenIDに対応するWebサイトやブログやフォーラムの数が増えるほど、各自が管理するログイン用パスワード数の負担を減らせることは確かなはずである。