OpenID: Specs

Status: picking up steam -- May 2005.

[About] [Specs] — [

Status] [

Mailing List] [

Wiki]

注意

この仕様は最初のプロトタイプで、コミュニティからのフィードバックを受けて若干の仕様変更をしています。この仕様に基づいて実装しないでください。

OpenID のカラクリ

あるブログをメンテしているとします。そしてそれが、例えば livejournal.com で（他のものでも構いませんが）、あなたは常にそこにログインしているとします。
次に、someblog.com （MovableType や Wordpress、DeadJournal などなどでしょう）にコメントを付けたいと思ったとします。ところがコメントをつける先には、あなたはアカウントを持っていません。こうなると、認証つきのコメントを残す術がありません。ここで、もしコメントをつける先の blog システムが OpenID に対応しているとすると、次のようなものがついています（実際にはもっとカッコイイものでお願いします）。

Login with your blog URL:
For example: happygirl.bloghost.com
何も付いていなければ、"http://" が先頭についていると仮定する挙動を、仕様としては推奨します。こうしておくと、"bob.livejournal.com" を ID として使えるようになります。
またフォームフィールドを openid_url という名前に固定しておくと、ブラウザのオートコンプリート機能が効果的に働いて、異なるサイトであってもユーザの URL 補完が効くようになります。これは、e-コマースの業界で "address1" や "address2" といった名前の使い方と同様のやり方です。
AJAX バージョンでは、ログインボタンを押すとサーバに対して XMLHttpRequest/IFRAME POST され、「この URL を調べてくれ！」という問い合わせが実行されます。サーバは、ユーザの ID として指定された URL の内容を取得します。もし中身が HTML であれば、
<link rel="openid.server" href="http://www.livejournal.com/auth/?type=openid" />
といった形をしている、OpenID <link> auto-discovery タグを探します。 href はユーザの ID に関する全ての通信を受け持つものになります。 URL に引数がついている場合は、それもきちんと処理してあげましょう……切り捨ててはいけません。 ID を確認する（サーバ）側が link タグの付いているページにたどり着くまでにリダイレクションを何回か踏んだ場合は、最後のページを処理対象の ID URL として扱います。これはユーザのタイプしたものとは異なるかもしれない、ということに注意してください。また、生のホスト名（"bradfitz.com"）をパス無しで指定した場合は、 "http://" プレフィックスに加えて、パスとしては "/" が仮定されているとします。 "bradfitz.com" は（先ほど述べたようにリダイレクションされなければ）"http://bradfitz.com/" になります。
ID コンシューマ上のヘルパープログラムは、クライアントブラウザに次の項目を返します：
- ユーザの使用している ID サーバの正式な URL（正式版を取得する法則は上記に従います）
- ユーザの ID サーバの URL（HTML を取得したホストとはまた別のサーバかもしれません）
クライアントブラウザは ID サーバに対して隠し IFRAME を開いて、次の URL 引数をセットします：（注 URL に既についている引数をきちんと残すことは重要です。単純に "?" で次の引数を連結してはいけません。ただし、これから指定する名前が引数に既についていた場合、これらを除去しても構いません。"openid." で始まる引数を、その ID サーバが独自仕様として使うことはありえないからです。）
- openid.mode -- checkid_immediate あるいは checkid_setup という値になります。 'immediate' モードは、署名確認フローに入る前にユーザが訪れることになる、フォーム中の user_setup_url に記載されている場所に、署名確認成功時あるいは失敗時に ID サーバが即座にリダイレクションを行うことを示します。setup モードは、非 AJAX モードで使われるもので、 ID サーバがユーザーエージェントの制御を行い、HTML ページを返したり、リダイレクトしたり等などを行えるようにします。この方法は、ユーザの動きを記録したり、trust 状態をセットアップしたり、その他諸々の処理に必要なことを行うために使います。 setup モードでは、下に記載されているように、最終的なステップは ID サーバが return_to URL に差し戻すことで完了します。
- openid.return_to -- ID サーバがユーザに送るリダイレクト先 URL。クエリーストリングが付いているかもしれません。 ID サーバはそれを維持しなければいけません。
- openid.trust_root （なくてもいい。けど、あったほうがいい） -- ユーザが実際に承認する URL。 return_to URL は trust_root の下になければいけません。その条件が満たされない場合は、ID サーバは、リダイレクションの代わりにエラーを返します。つまり、URL スキームとポートも一致しないといけません。 path が存在する場合は、trust_root 以下でかつドメインも完全一致しているか、あるいは、 trust_root には http://*.livejournal.com といったワイルドカードが使えます（ただしワイルドカードは先頭だけです）。 http://*.com/ や http://*.co.uk/ を渡そうとすることもできますが、ID サーバがそれぞれにそういった入力を拒否するでしょう。trust_root が指定されていない場合は、return_to がデフォルト値として使われます。
- openid.is_identity -- クライアントが確認しようとしている ID URL。「この URL の自分のサイトにログインしていて、かつ、trust_root （つまり return_to URL を含む）がそのことを知っても良いか？」という問い合わせになります（「誰がログインしている？」という問い合わせではありません）。注ID サーバは自分自身が直接的に管理・発行している URL についてのみ処理するべきです。もし ID サーバで任意の人の URL を処理できるようにしたいとするならば、オフサイト URL 上で指定してある ID サーバの URL には、ID サーバのどのユーザ名を使っているかを示す追加パラメータを持つようになっていないといけません。（TODO: 別ページに "Ambigous Loop Problem"循環問題について書くべし）
ここまで来ると、次は return_to URL への HTTP リダイレクトを返します。この時には次のような引数が追加されています（return_to URL に既に query string がついている場合は、それも維持します）。
- openid.mode = id_res
- （条件に応じて） openid.user_setup_url = [url] ID が処理できなかったとき、処理できるようにするためにユーザができること、例えば、ログインし、パーミッションを与える、などのことをするための URL を返します。何故処理に失敗したのか分からないままになると困るので、何が必要になるかを明示的に示さないような URL を返すべきではありません（訳注：明示的に失敗した理由を示すようにしましょう）。
  
  ID コンシューマ側サイトは、user_setup_url へとユーザーエージェントを送る前に、次のオプションをつけてこの URL をチェックさせることもできます。
  - openid.post_grant （なくてもいい） -- ユーザによる trust_root 承認後に ID サーバがどういう挙動をして欲しいか。指定されていない場合は、動作は不定です。この値は、close （Javascript window.open や _blank ターゲットウィンドウで開いている場合、ウィンドウを閉じる。）または、もとの return_to URL に戻ってくることを示す return です。
- もし仮に、次の三つの条件が満たされていた場合は（訳注：下に続く）：
  1. あるユーザがログインしている
  2. openid.is_identity リクエスト引数で問い合わせている URL は、そのユーザの制御下のものである
  3. ID サーバ（例えば LiveJournal）に対して、「openid.trust_root URL が自分の ID をチェックしても良い」ということを伝えておく。
  これらが満たされていると、次の引数付きで返答が返ってきます
  - openid.assert_identity この値は openid.is_identity リクエストで送ったのと同じ値になっている
  - openid.return_to openid.return_to でもともとリクエストしたのと同じ値になっている。この値は、レスポンスで追加される引数を除けば、現在の URL と同じものです。
  - openid.timestamp w3c 形式のタイムスタンプ。UTC タイムゾーンでなければいけなくて、つまり "Z" 付きです："2005-05-15T17:11:51Z"。ID を確認する側では、署名がある時間範囲内で有効かどうかを見極めるのに使うこともできます。
  - openid.sig BASE64(DSA(SHA1("[timestamp]::assert_identity::[assert_identity]::[return_to]"))) の DSA 署名。DSA は ASN1 スキーマ SEQUENCE(INTEGER,INTEGER) を DER エンコードする関数で、ここでの二つの INTEGER は DSA の "r" と "s" です。また当然のことながら、URL に入れるときには全体を URL エスケープします。
IFRAME は先ほどまで他ドメインをロードしていましたが、ここまで来ると、再び同一ドメイン内からロードしています。return_to URL では HTML ページを生成され、そのページ内にある JavaScript は window location hostname と親 location hostname が同じであることを検査します（これが満たされていない場合はセキュリティ例外が投げられます）。その後、OpenID ライブラリの登録されている親ウィンドウの領域に応答を描画して ID 確認と DSA 署名を自動的に伝播させるか、あるいは、ユーザが URL を自分で表示させます。
コメントなどを someblog.com サーバに投稿する際に identity URL, DSA 署名, 処理タイムスタンプを同時に提出すると、サーバ（訳注：someblog.com）は ID サーバ公開鍵をキャッシュから取得するか、あるいは、openid.mode の値を getpubkey にして引数としてつけて ID サーバ URL に問い合わせて DSA 公開鍵を PEM 形式で直接取得します。注： POST を送出したときに、アプリケーションが返す ID サーバ URL を盲目的に受け入れるのではなく、サーバは ID URL の ID サーバの値を（キャッシュを使うことになると思いますが）、検査すべきです。
まとめると、この処理の流れでできることは：OpenID 対応のサイトでは ID URL で本人確認できて、その ID URL を所有している人のみが認証できるが、他の人はその ID を詐称することができない ということになります。加えて述べるのと、このシステムでは正当なユーザの手を煩わせることなく（ユーザは URL にログインして、「コメント先の URL を信用する」とID サーバに伝えるだけです）、悪質なサイトが個人の ID を抜き取れないようにします。

その他メモ

URL の長さ制限：

Identity URL: 最大 255 バイト
Identity server URL: 最大 2047 バイト （ID コンシューマ側が URL に引数を追加した後の長さで。なので、生のエンドポイント URL はこれよりもずっと短いです。）
return_to URL: 最大 2047 バイト （ID サーバが URL に引数を追加した後の長さで。なので、return_to URL はこれよりずっと短いです。）