OpenIDが出来る事
ユーザーが「あるOpenIDプロバイダにアカウントを持っていること」をウェブアプリに証明する
基本的にはたったこれだけ。OAuthとの違いウェブアプリに何らかの権限や、ランダム生成された識別子以上の情報を渡すことはない。
OpenIDログインを利用するウェブアプリ（リライングパーティー）が知ることができるのは
・ユーザーがどのプロバイダのIDを持っているか
・ユーザーの所有する識別子（乱数）
OpenIDを発行する側（OpenIDプロバイダと呼ばれる）が知ることが出来るのは、
・ユーザーがどのウェブアプリ（リライングパーティーと呼ばれる）にアクセスしたか
だけになる。正しく実装されたOpenIDでは、OpenIDプロバイダにどのような情報が登録されているか（メールアドレスやパスワードなど）は、リライングパーティにはわたらない。
仕組み
OpenIDではおおよそ次のような認証手順をふむ。
ユーザーがリライングパーティのウェブサイトにアクセスする。
ユーザーが「OpenIDでログイン」を選択
＝ ユーザー→リライングパーティ「私はとあるプロバイダが発行したOpenIDを持っています」
リライングパーティはブラウザをOpenIDプロバイダのページへリダイレクトする
＝リライングパーティ→ブラウザ「問い合わせメッセージを渡すので、それに署名してもらってきてください」
ここからブラウザはOpenIDプロバイダのページを表示する
ブラウザはリライングパーティが発行したメッセージへの署名要求を送る
＝ブラウザ→プロバイダ「このメッセージに、アカウントを持っていることを証明する署名をください」
OpenIDプロバイダはOpenIDプロバイダ自身のログイン画面を表示する
＝OpenIDプロバイダ→ユーザー「あなたは誰ですか？」
ユーザ―はOpenIDプロバイダでのIDとパスワードなどを入力する
＝ユーザー→OpenIDプロバイダ「ユーザーID foo、パスワードbarです。」
OpenIDプロバイダはユーザーへの確認画面を表示する
＝プロバイダ「このウェブアプリ（リライングパーティ）に対してあなたの識別子を証明していいですか？」
ユーザーがOKをクリック
OpenIDプロバイダはメッセージへの署名と識別子をブラウザに渡す
＝プロバイダ→ブラウザ「この署名と識別子を持ってリライングパーティのページに行ってください」
ここからブラウザはリライングパーティのウェブページにもどる
ブラウザは署名済みメッセージをリライングパーティに送る
＝ブラウザ→リライングパーティ「このOpenID識別子をもっている事を証明します」
リライングパーティはサードパーティの署名を検証して、識別子とユーザーを紐つけて保存する。
これでリライングパーティは、「ユーザーがOpenIDプロバイダにアカウントを持っていること」と「ユーザーの（ランダム生成された）識別子」を保証できる。
OpenIDプロバイダに保存されている情報は、ユーザーの識別子以外、なにも漏れていない。例えば、Google発行ののOpenIDを使っても、GmailアドレスやGoogle+アカウントの個人情報が漏れることは無い。
具体的方法は
http://openid-foundation-japan.github.io/openid-authentication.html
に日訳があった。
OpenIDの問題点
現在普及していないことから分かるように欠点もある。
2つのウェブアプリの間での紐付け
古いOpenID実装では、ユーザーは一つのOpenIDプロバイダにたった一つだけ固有の識別子をもつ。つまり、2つのウェブアプリが提携すると、それぞれにログインしたユーザーが同一人物であることをOpenID識別子が一致することから知られてしまう。（もっとも、サードパーティクッキーやIPアドレスによる追跡の方がずっと強力だが）
OpenIDプロバイダはこの問題に、リライングパーティ毎に個別の識別子を生成することで対処できる。つまり、あるウェブアプリAにユーザーfoobarがログインする時にはOpenID識別子として123456を返し、ウェブアプリNには7890123、というふうにしてしまえば、識別子から紐付けされることはない。OpenID2.0では、ユーザーはOpenIDプロバイダの名前さえ覚えておけば、識別子はOpenIDプロバイダが自動生成してくれる。
ユーザーの誤認・フィッシング
OpenIDを実装すると、異なるウェブサイト間をリダイレクトで自動的に移動することになる。これはユーザーを混乱させる元になる。
悪意あるリライングパーティは、OpenIDプロバイダにリダイレクトしたと見せかけて、プロバイダのログイン画面を模倣したフィッシングサイトにユーザーをリダイレクト出来る。
直接的な対処法がなく、ユーザーにフィッシング対策の知識が一定以上有ることを期待するしかない。OpenIDプロバイダになる＝フィッシングリスクを高める事になり、一般向けに開放することが難しい。
逆向き（OpenIDプロバイダからリライングパーティ）も同様で、信頼出来ないOpenIDプロバイダが、リライングパーティを模倣したフィッシングサイトを作ることで、ユーザーがリライングパーティにポストしようとした内容を詐取する可能性がある。
OpenIDを導入するにあたっては、リダイレクト前後に特徴的なページ（例えば、ユーザ専用のアイコン画像や背景色など）を挿入するなど、ウェブサイトの識別性を高めるフィッシング対策をとる必要がある。
例えば、Yahooはログイン画面に好きな画像を登録できる。
OpenIDプロバイダの信頼性
OpenIDプロバイダが侵入されるなどで、認証システムが乗っ取られると、そのOpenIDを利用してログインしている全てのウェブアプリが同時に脅威にさらされる。
OpenIDの原理上、OpenIDプロバイダにはどのリライングパーティにアクセスしたかの履歴が残るので、侵入に成功した攻撃者は入手したOpenIDでどのウェブサイトにログイン出来るか瞬時に分かってしまう。
通常のパスワード漏洩では、他のサイトはログイン失敗したパスワードのパターンを調査することで、漏洩リストによる攻撃の徴候を検出することが可能だが、OpenIDプロバイダ自体の脆弱性ではそもそもログインに失敗することが無いので、不正ログイン検出が難しくなる。
対処法としては、プロバイダの脆弱性が発覚した時点でリライングパーティ側は該当するOpenIDプロバイダのユーザー全員をログアウトさせ、OpenIDプロバイダの信頼性が復旧した後にログインし直す事を要求する。
OpenID認証の代替手段
OpenIDプロバイダがクラックされた場合、上記のように一時的とはいえリライングパーティ側は、そのOpenIDプロバイダを利用した認証を無効化する必要に迫られる。（念の為、OpenIDプロバイダ側に総パスワードリセットなどの復旧手段があれば、アカウントが完全に失われることは避けられる） ユーザー認証を完全にOpenIDに頼っている場合、その間ユーザーが安全にログインする手段がなくなってしまう。
リアルタイムのアクティブアユーザー数が直接利益に関わるウェブアプリでは、アカウントを失うリスクを減らすために、リライングパーティ側でも、ユーザーのメールアドレスなど、ユーザーへの信頼出来る到達手段を用意しておく必要があり、これはOpenIDの利点を相殺する。
サードパーティ認証との識別性
OpenIDそのものの認知度が低く、単なるサードパーティ認証やOAuthとの違いがユーザーに理解されていない。
そのため、メールアドレス漏洩やアカウント機能の不正利用についての懸念がOpenIDの利用を阻害する。
ラベル：OpenID
