検索
連載

仕様から学ぶOpenIDのキホンOpenIDの仕様と技術(1)(3/3 ページ)

にわかに注目を集めている、URLをIDとして利用する認証プロトコル、OpenID。本連載ではこのプロトコルの仕組みを技術的に解説するとともに、OpenIDが今後どのように活用されていくのかを紹介する(編集部)

PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ |       

保存版・OpenID1.1の用語集

 ここでも公式の仕様の中の用語集から説明します。

●End User
実際にConsumerに対して自分のIdentityを認証しようとするユーザーのことです。

●Identifier
IdentifierはURLのことです。OpenID authentication protocolのすべてのフローはEnd Userが所有するURLを認証することに関するものです。

●Claimed Identifier
End Userが自分で所有していると主張するIdentifierのことで、Consumerによってまだ確認されていないIdentifierです。

●Verified Identifier
Consumerに対して、End Userが所有していると認められたIdentifierのことです。

●Consumer
End Userが所有するClaimed Identifierの認証を、IdPに対して要求するWebサービスのことです。

●Identity Provider
IdP(Identify Provider)やServerとも呼ばれます。ConsumerがEnd Userが所有するClaimed Identifierの暗号化された証明に対してコンタクトを取る相手がIdentify Provider(以下、IdP)です。どのようにしてEnd Userが自分を認証するIdPに対して自分のIdentityを証明するかはOpenID Authenticationの範囲外です【注3】

【注3】

OpenIDの仕様上、誰でもConsumerやIdPになれるという点から、特にConsumerはどのIdPを信用したらよいかという問題が残ります。

これに関しては現行仕様の中では触れていませんし、現時点で有効な解決策も見つかっていません。詳しく知りたい方はopenid-jaグループの以下のスレッドを参照してください。

How to authorize the identity providers in OpenIDhttp://groups.google.co.jp/group/openid-ja/browse_thread/thread/24237e403a7ef82a?hl=ja


●User-Agent
End Userが所有するWebブラウザのことです。特別なプラグインやJavaScriptの実行環境は必要ありません。


 この用語集に出てくる言葉はいわばOpenIDにおける登場人物のようなものです。仕様書の訳なので若干難しいですが、下記のようなシナリオを描くと理解しやすいと思います。

Consumerが提供するWebサービスはOpenID Authenticationに対応しています。

いまこのWebサービスを利用したいと考えるEnd Userがいて、そのEnd UserはOpenID Authentication protocolをサポートしたIdPによって認証されるIdentifierを所有しています。

End UserはConsumerに確認されていないClaimed IdentifierをConsumerに提示することにより、ConsumerはIdPと連携し、End UserのUser-Agent経由で認証を行い、Verified Identifierとします。

図3 OpenIDのシナリオ
図3 OpenIDのシナリオ

 さて、ここで一度まとめておきましょう。

  • OpenIDにおけるIDとはURLのことである。
  • End Userは自分のClaimed IdentifierConsumerに対して認証してくれるIdPに加入していなければならない。End UserはどのIdPに加入していても良く、ConsumerはいずれのIdPであっても協調してEnd UserClaimed Identifierの認証手続きを行わなければならない。
  • IdPがConsumerに対して認証するのはEnd UserClaimed Identifier、即ちURLが、End Userが確かに所有しているかどうかということである。

 これらから分かるように、OpenIDは個人のアイデンティティをURLとして表現し、分散型の認証方式を提供するオープンな認証システムだといえます。

 次回はこれらを押さえたうえで、実際にどのような手続きによってClaimed IdentifierがVerified Identifierとなるのかを紹介します。

Profile

サイボウズ・ラボ株式会社

山口 徹(やまぐち とおる)

サイボウズ・ラボ株式会社のプログラマー。

バーテンダーからIT業界に転身後、様々なWeb制作を行い、大規模コミュニティサイトの開発・運用を経て、現在は研究開発の日々。Perl使い。

Perlを中心とした開発のノウハウやネタをShibuya Perl Mongersのイベント等で発表するなど講演活動も行う。

個人の開発日記は「Yet Another Hackadelic」、仕事のブログは「log4ZIGOROu


●修正履歴

【2007/7/9】

初出時に「Authentication(認証)」と「Authorize(認可)」について、訳語・用法が不適切な部分がございました。本用語について全体的に見直しを行い、修正・加筆いたしました。



Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       

Security & Trust 記事ランキング

  1. 2025年、LLMの脆弱性が明確になるなど、セキュリティとクラウドに関する8つの変化
  2. 「SMSは認証に使わないで」 米CISA、モバイル通信を保護する8つのベストプラクティスを公開
  3. “ゼロトラスト”とトラスト(信頼性)ゼロを分かつものとは――情報セキュリティ啓発アニメ「こうしす!」監督が中小企業目線で語る
  4. Google Cloud、2025年のサイバーセキュリティ予測を発表 AIがサイバー攻撃にもたらす影響とは?
  5. 2025年に押さえるべきセキュリティの重要論点をガートナーが発表 新しいリスク、脅威、環境の変化、法規制などの動きを把握する指標に使える
  6. 終わらせましょう。複雑過ぎるKubernetes/クラウドネイティブが生む心理的安全性の低下を――無料でクラウドセキュリティの勘所が分かる130ページの電子書籍
  7. よく聞く「複雑化するサイバー攻撃」は具体的にどう複雑なのか? 一例を医療系企業のランサム事例とともに解説
  8. 経営層の約7割が「セキュリティ対策は十分」一方で6割以上がインシデントを経験、1位の要因は?
  9. ゼロトラストの理想と現実を立命館大学 上原教授が語る――本当に運用できるか? 最後は“人”を信用できるかどうか
  10. NIST、3つのポスト量子暗号(PQC)標準(FIPS 203〜205)を発表 量子コンピュータ悪用に耐える暗号化アルゴリズム、どう決めた?
ページトップに戻る