あなたのサイトをOpenID対応にしている2行の意味OpenIDの仕様と技術(2)(1/3 ページ)

OpenIDが知られるようになり、自分のURLにおいたHTMLヘッダに、link rel="openid.server"……から始まる2行を追加することで、自分のURLをIDとして利用ができる、ということを知っている方も多いかと思います。今回はヘッダに書かれた2行が、OpenIDの仕様ではどのように定義され、利用されているのかを解説します(編集部)

» 2007年08月10日 00時00分 公開
[山口徹サイボウズ・ラボ株式会社]

 第1回ではOpenIDの基礎知識を取り上げ、登場する用語について説明していきました。今回は動作の概要として、具体的にClaimed IdentifierがVerified Identifierとなるための手続きについて説明します。前回紹介した用語をもう一度復習しながら読んでみてください。

Claimed Identifierの宣言

 まずはOpenIDの動作概要について説明します。End UserがどのようにしてConsumerに対して自分のClaimed Identifierを認証するIdP(Identity Provider)を知らせるかについて学びましょう。

IdPの宣言

 End Userは自分のClaimed Identifierを認証してくれるIdPを明示する必要があります。

 この明示の仕方ですが、具体的にはそのClaimed IdentifierをWebブラウザで開いたときに表示されるhead要素の中にlink要素として、下記のように記載します。

<link rel="openid.server"  href="http://example.openid-idp.com/server" />

 このlink要素の各属性について解説すると、

"openid.server"

・rel

openid.serverと記載します。

・ href

IdPが提供するサーバのエンドポイントURLを記載します。


となります。

図1 IdPの宣言 図1 IdPの宣言

 HTML文書中の宣言がこの1つで済むのは、サーバのエンドポイントURLが同一ホストにある場合のみです【注1】

【注1】

サブドメインは異なっても構いません。


Delegateの仕組みについて

 当然ながら、End UserがClaimed Identifierとして用いるURLのホストと同一ホストでIdPを立ち上げなければならないわけではありません。自分のClaimed Identifierを認証する認証サーバーと、認証サーバーと同一ホストにあるIdentifierを明示する事によって、元のClaimed Identifierの認証を外部の認証サーバーに委ねることができます。

 具体的にはhead要素の子要素として、下記のように記載します。

<link rel="openid.server"  href="http://example.openid-idp.com/server" />
<link rel="openid.delegate"  href="http://example.openid-idp.com/user/zigorou" />

 link要素の各属性について解説すると、

"openid.delegate"

・rel

openid.delegateと記載します。

・ href

IdPと同一ホストのClaimed Identifierとして使用するURLを記載します。


となります。

 このようにHTML文書中のlink要素として指定されたフォーマットで情報を記載しておくことによって、ConsumerはEnd UserからClaimed Identifierを受け取ったときに、どのIdPに問い合わせればよいかが分かります。

図2 delegateの仕組み 図2 delegateの仕組み

 OpenIDで使うlink要素で指定するURLに関していくつか注意点があります。

  • openid.serverのURL(href属性値)はクエリーパラメータを含む場合があります。このクエリパラメータの開始記号である「?」は必ず1つにしてください。
  • openid.server、openid.delegateのURLは絶対URLでなければなりません。
  • openid.server、openid.delegateのURLは「&」、「」、「"」を除いた実体参照を含めてはいけません。またURL中に含めてはならない文字列は正しくURLエンコードをしていなければなりません。

 基本的には常識的なことですが、注意しましょう。

URLをIdentifierとするメリットとデメリット

●メリット

 OpenIDではIdentifierはURLそのものであり、なおかつopenid.server、openid.delegateの解決のためにHTML、もしくはXHTMLで表現する必要があります。

 HTML文書で記述できるということは、Identifierに対して豊富なメタデータの提供を行うことができます。

 参考程度にLive Journalの中の私のページのhead要素内からメタデータを抽出すると、

  • RSS Feed
  • Atom Feed
  • FOAF

などが挙げられます。

 また、マイクロフォーマットなどを利用してHTML文書をよりセマンティックな形でマークアップすることにより、Identifierから機械的にそのEnd Userのメタデータを引き出すことが可能になります。あるいは当然ブラウザで表示することも可能でしょうから、人間にとってもそのIdentifierを持つに際して、何らかの情報が得られる可能性が高いでしょう。

 さらにいえば、URL中には、httpないしはhttpsの場合はホスト名が含まれるものがほとんどですので、例えば特定のco.jpドメインを持つIdentifierに関していえば、そのIdentifierのHTMLがco.jpドメインを持つ会社ではない、まったく無関係の第三者がねつ造したページでない限りは、おおむねその会社の人であると信じてもよいでしょう。

 このように通常よくあるサイトでのIDは、暗黙の了解を除けばただの文字列にすぎないのに対して、OpenIDのIdentifierに関していえば、そのものに意味を見いだすことができるといえるでしょう。

●デメリット

  当然ながらデメリットも存在します。簡単に列挙すれば、

  • 認証サーバーは分散モデルなので複数存在することから、それらの認証サーバーを手放しに信頼してよいかどうか判断ができない。
  • 信頼できない認証サーバーで認証されたIdentifierへの認可はどのように行うか判断ができない。
  • URLをIdentifierとすることから、必然的にイントラネット内での利用が難しい。 【注2】

【注2】

Identifierがイントラネット内部にあるようなケースだと、外部ネットワークにあるConsumerがそのIdentifierのページを見ることができないので、少なくともConsumerからIdentifierが見える状態でないと利用できません。

Consumerもイントラネット内部にありIdentifierにURLが割り当てられているならば、問題なく利用することができるでしょう。


 これらに関してはいずれ深く言及したいと思います。

       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。