日向夏特殊応援部隊

俺様向けメモ

斜め読みOpenID Authentication 2.0 - Draft11 (3) Protocol Overview

OpenID

ソースはImplementor's Draft: OpenID Authentication 2.0 - Draft 11です。

Protocol Overview

  1. エンドユーザーはUser-Supplied Identifierを自分たちのUser-Agent経由でRPに表現する事から認証を開始します。*1
  2. User-Supplied Identifierを標準化した後に、その*2上で探索を実行し、エンドユーザーが認証の為に使うOP Endpoint URLを確立します。User-Supplied Identifierはセクション7.3.1で論議されているように、OPにおいてClaimed Identifierの選択を許可しているOP Identifier、あるいはClaimed Identifierを使う事無く実行するプロトコルの為に拡張経由でなされる何か他のより便利な物かもしれない。*3
  3. (オプション)Relying Party(アプリケーションの事。)とOPはDiffel-Hellman共通鍵交換を使って信頼関係を共通鍵によって構築する。OPはこの信頼関係(の確立を)次のメッセージの合図とし、RPはそのメッセージを確認するのに(信頼関係の確立を)利用する。この事は互いの認証リクエスト、レスポンスの後に引き続く次の直接的な署名確認の為のリクエストの必要性を取り除く。*4
  4. RPはエンドユーザーのUser-AgentをOpenID認証リクエストと共にOPにリダイレクトさせる。
  5. OPはエンドユーザーがOpenID Authenticationを実行する事により認証されるか、そうする事を望むかのいずれかを用意する。*5
  6. エンドユーザーが自分たちのOPで認証する際と、そのような認証の周囲にあるいかなる流儀の中での作法に関してはこの文書の範囲外である。
  7. OPはエンドユーザーのUser-Agentを認証が許可されたと言う主張あるいは認証が失敗したと言うメッセージと共にRPにリダイレクトさせる。
  8. RPはOPから受信したReturn URLの確認、得た情報の確認、目下の確認、信頼関係がある間に確立された共通鍵を使用するか、直接的なリクエストをOPに送信する事によって署名確認を行うと言ったような情報を確認する。

まとめ

なんで仕様ってこんなややこしいんだろうw
ざっくり言えば、

  1. ブラウザ経由で自分のIDをサービスに伝える。(サービス側にあるフォームとか多分使って)
  2. サービス側はそのIDから認証局のエンドポイントURLを見つける。
  3. オプションでDH鍵交換を使ってOPとサービス間で共通鍵を持っても良い。(後で余計なOPとサービス間の確認が無くなる)
  4. サービスは認証要求と共にブラウザごとOPに飛ばす。
  5. 認証を実行するかあるいは認証フォームを出す。
  6. OPは認証結果と共にユーザーをサービスにリダイレクトさせる。
  7. サービス側はOPから受け取ったデータの検証をする

って感じですかね。

*1:つまるところエンドユーザーは自分たちのIDをブラウザ経由でアプリケーションに伝えるよって事

*2:User-Supplied Identifierの事

*3:うあ、、、、意味わかんね。。。

*4:鍵交換してればやらなくて良い？

*5:いきなり認証させるのか、あるいは自らがアカウント情報を入力して認証するように認証フォームを用意するかって事かな？