斜め読みOpenID Authentication 1.1 Overview (1)
d:id:ZIGOROu:20070319:1174304910 の続きです。
OpenID Authentication 1.1がソースです。
HTMLドキュメントをアイデンティティへと変換する
エンドユーザーはアイデンティティとしたいURLにあるHTMLドキュメントのhead要素内に指定されたlink要素を入れなければならない。
エンドユーザーがアイデンティティとして使用するホストはエンドユーザーのIdPである必要は無い。
例えばエンドユーザーのアイデンティティがhttp://example.com/だとして、http://openid.example.comがIdP*1の場合はhttp://example.com/のhead要素内に下記のようなlink要素を記載しなければならない。
<link rel="openid.server" href="http://openid.example.com/" />
認証の委譲(delegating)
エンドユーザーのアイデンティティがあるホストにIdPが無い場合や、他のホストでIdPを運用したい場合は認証を(他のホストに)委譲する必要が出てくる。
例えばエンドユーザーがexampleuserと言ったidでLiveJournalのアカウントを持っている場合、LiveJournalはOpenIDのIdPでもあるから、
http://exampleuser.livejournal.com/に認証の委譲を行う事が可能である。
example.comをアイデンティティとしてつかう為にコンシューマーは実際にはhttp://exampleuser.livejournal.com/をIdPと共に確認する為に、
example.comのhead要素内に下記のようなlink要素を追加する必要がある。
<link rel="openid.server" href="http://www.livejournal.com/openid/server.bml" /> <link rel="openid.delelgate" href="http://exampleuser.livejournal.com/" />
delegatingをつかうメリットは自分のアイデンティティをexample.comとして長く使用出来るという事で、
途中で自分のIdPを変更したりする事も出来るという点がある。
重要な注意点
- openid.serverのURL宣言*2はQueryパラメーターを含むかもしれない。従って既にQueryパラメーターの開始記号であるクエスチョンが存在するならば、2個目のクエスチョンは「追加してはならない。
- openid.server, openid.delegateのURLは共に絶対URLで無ければならない。コンシューマーは相対URLの解決に注意を払う必要が無い。
- openid.server, openid.delegateのURLは&,<.>,"を除いた実体参照を含めてはならない。また妥当なhtml文書でない文字列、文書のエンコーディングで表現出来ない文字列はRFC2396正しくURLエンコーディングされていなければならない。
まとめ
- delegatingを使わない状況だとIdPとIdentityは同一hostじゃないと駄目みたいですね。サブドメインならOKみたい。
- delegatingは要するにIdentityの実体を他の場所に指定する方法と思えば良さそう。
ふむ。
*1:Identity Providerの事。d:id:ZIGOROu:20070319:1174304910参照
*2:link要素のhrefの中の事