オープンID

ロゴ

OpenIDは、非営利団体のOpenID Foundationが推進するオープンスタンダードの分散認証プロトコルです。OpenIDでは、サードパーティのアイデンティティプロバイダ（IDP）サービスを利用して、協力サイト（リライングパーティ、またはRPと呼ばれる）によるユーザー認証が可能になり、ウェブマスターが独自のアドホックログインシステムを提供する必要がなくなり、ユーザーは複数の無関係なウェブサイトにそれぞれ別々のIDとパスワードを持つことなくログインできるようになります。[ 1 ]ユーザーはOpenIDアイデンティティプロバイダを選択してアカウントを作成し、[ 1 ]そのアカウントを使用して、OpenID認証を受け入れる任意のウェブサイトにサインオンします。多くの大規模組織が、自社のウェブサイトでOpenIDを発行または受け入れています。[ 2 ]

OpenID標準は、アイデンティティプロバイダーとOpenIDアクセプタ（「リライングパーティ」）の間で行われるべき通信のフレームワークを提供します。[ 3 ]標準の拡張（OpenID属性交換）により、名前や性別などのユーザー属性をOpenIDアイデンティティプロバイダーからリライングパーティに転送することが容易になります（各リライングパーティは、それぞれの要件に応じて異なる属性セットを要求することができます）。[ 4 ] OpenIDプロトコルは、ユーザーのアイデンティティを認証するために中央機関に依存しません。さらに、サービスもOpenID標準も、ユーザーを認証するための特定の手段を義務付けることはできず、一般的な方法（パスワードなど）から新しい方法（スマートカードや生体認証など）まで、さまざまな方法が可能です。

OpenIDの最終バージョンはOpenID 2.0で、2007年12月に完成・公開されました。[ 5 ] OpenIDという用語は、OpenID標準で指定された識別子を指す場合もあります。これらの識別子は、一意のUniform Resource Identifier （URI）の形式を取り、認証を処理する「OpenIDプロバイダー」によって管理されます。[ 1 ]

採択

2016年3月現在、インターネット上には10億を超えるOpenID対応アカウントがあり（下記参照）、約1,100,934のサイトがOpenIDコンシューマーサポートを統合しています：[ 6 ] AOL、Flickr、Google、Amazon.com、Canonical（プロバイダー名： Ubuntu One）、LiveJournal、Microsoft（プロバイダー名：Microsoftアカウント）、Mixi、Myspace、Novell、OpenStreetMap、Orange、Sears、Sun、Telecom Italia、Universal Music Group、VeriSign、WordPress、Yahoo!、BBC、[ 7 ] IBM、[ 8 ] PayPal、[ 9 ] Steam 、[ 10 ]ただし、これらの組織の中には独自の認証管理を行っているところもあります 。

大規模組織の多くは、アカウント登録（OpenID IDとして利用可能）に既存のメールアドレスまたは携帯電話番号による認証情報の提供を求めています。小規模な組織の中には、追加のID情報を必要とせずに登録を受け付けているところもあります。

Facebookは過去にOpenIDを使用していましたが、Facebook Connectに移行しました。[ 11 ] BloggerもOpenIDを使用していましたが、2018年5月以降はサポートされなくなりました。[ 12 ]

技術概要

OpenIDは、ユーザーが単一の認証情報セットを使用して複数のウェブサイトで認証できるようにする分散型認証プロトコルです。これにより、ウェブサイトごとに別々のユーザー名とパスワードを使用する必要がなくなります。OpenIDは、アイデンティティプロバイダ（IdP）を介してユーザーを認証し、IdPはユーザーに固有の識別子（OpenID）を提供します。この識別子は、OpenIDをサポートするあらゆるウェブサイトでユーザーを認証するために使用できます。

ユーザーがOpenID認証をサポートするウェブサイトにアクセスすると、ウェブサイトはユーザーを選択したIdPにリダイレクトします。IdPはユーザーに認証（ユーザー名とパスワードの入力など）を求めます。ユーザーが認証されると、IdPはOpenIDを生成し、ウェブサイトに返送します。ウェブサイトは、このOpenIDを使用してユーザーを認証できるため、ユーザーの実際の認証情報を知る必要はありません。

OpenIDは、HTTP、HTML、XMLなど、既存の標準規格を基盤として構築されています。OpenIDは、ウェブサイトが特定のOpenIDに関連付けられたIdPを見つけるための検出メカニズムや、フィッシングなどの攻撃から保護するためのセキュリティメカニズムなど、様々な技術に依存しています。[ 13 ]

OpenIDの主な利点の一つは、ユーザーがログイン認証情報の保存と管理を個々のウェブサイトに頼るのではなく、自身のID情報を管理できることです。これは、ウェブサイトがセキュリティ侵害に対して脆弱な場合や、ユーザーが個人情報のプライバシーを懸念している場合に特に重要です。

OpenIDは、Google、Yahoo!、PayPalなど、多くの大規模ウェブサイトやサービスプロバイダーに広く採用されています。また、Ruby on RailsやDjangoなど、多くのオープンソースプロジェクトやフレームワークでも使用されています。

ログイン

エンドユーザーは、認証のためにOpenIDを指定するオプションを提供するリライングパーティ（ウェブサイトなど）と対話します。エンドユーザーは通常、alice.openid.example.orgOpenIDプロバイダ（例openid.example.org：）にOpenID（例：）を事前に登録しています。[ 1 ]

通常、依存パーティは OpenID を正規の URL 形式 (例http://alice.openid.example.org/) に変換します。

  • OpenID 1.0では、証明書利用者はURLで識別されるHTMLリソースをリクエストし、HTMLリンクタグを読み取ってOpenIDプロバイダーのURL（例： ）を検出します。また、証明書利用者は委任されたIDhttp://openid.example.org/openid-auth.phpを使用するかどうかも検出します（下記参照）。
  • OpenID 2.0 では、依存パーティはコンテンツ タイプを持つXRDSドキュメント( Yadisドキュメントとも呼ばれる) を要求することによって OpenID プロバイダー URL を検出します。このドキュメントはターゲット URL で利用できる場合があり、ターゲットXRIapplication/xrds+xmlでは常に利用できます。

依存パーティが OpenID プロバイダーと通信できるモードは 2 つあります。

  • checkid_immediateは、リライングパーティがOpenIDプロバイダに対し、エンドユーザーとやり取りしないよう要求するものです。すべての通信は、エンドユーザーに明示的に通知することなく、エンドユーザーのユーザーエージェントを介して中継されます。
  • checkid_setupこの場合、エンド ユーザーは、依存パーティへのアクセスに使用したのと同じユーザー エージェントを介して OpenID プロバイダーと通信します。

操作を自動化できない場合は、モード にcheckid_immediateフォールバックできます。checkid_setup

まず、証明書利用者とOpenIDプロバイダ（オプション）は、関連ハンドルによって参照される共有秘密鍵を確立し、証明書利用者はそれを保存します。モードを使用する場合、証明書利用者はエンドユーザーのユーザーエージェントをOpenIDプロバイダにリダイレクトし、エンドユーザーはOpenIDプロバイダで直接認証できます。 checkid_setup

認証の方法はさまざまですが、通常、OpenID プロバイダーはエンド ユーザーにパスワードまたは何らかの暗号化トークンの入力を求め、次に、エンド ユーザーが必要な ID の詳細を受け取るために依存当事者を信頼するかどうかを尋ねます。

エンド ユーザーが OpenID プロバイダーの依存パーティを信頼する要求を拒否した場合、ユーザー エージェントは認証が拒否されたことを示すメッセージとともに依存パーティにリダイレクトされ、依存パーティはエンド ユーザーの認証を拒否します。

エンドユーザーが OpenID プロバイダーの証明書利用者への信頼要求を受け入れると、ユーザーエージェントはエンドユーザーの資格情報とともに証明書利用者にリダイレクトされます。証明書利用者は、資格情報が本当に OpenID プロバイダーから送信されたものであることを確認する必要があります。証明書利用者と OpenID プロバイダーが以前に共有秘密鍵を確立している場合、証明書利用者は、共有秘密鍵のコピーをエンドユーザーの資格情報とともに受信したものと比較することで、OpenID プロバイダーの ID を検証できます。このような証明書利用者は、セッション間で共有秘密鍵を保存するため、ステートフルと呼ばれます。一方、ステートレスまたはダムな証明書利用者は、データが本当に OpenID プロバイダーから送信されたものであることを確認するために、 バックグラウンド要求 ( ) をもう 1 つ行う必要があります。check_authentication

OpenIDが検証されると、認証は成功とみなされ、エンドユーザーは指定されたOpenID（例：alice.openid.example.org）で指定されたIDを使用して証明書利用者にログインしたとみなされます。証明書利用者は通常、エンドユーザーのOpenIDをエンドユーザーのその他のセッション情報と共に保存します。

識別子

OpenID対応ウェブサイトへのログインに使用できるOpenID対応URLを取得するには、ユーザーはアイデンティティプロバイダにOpenID識別子を登録します。アイデンティティプロバイダは、OpenID認証サービスが自動的に設定されるURL（通常はサードレベルドメイン、例：username.example.com）を登録する機能を提供しています。

OpenIDを登録すると、ユーザーは自身の管理下にある既存のURL（ブログやホームページなど）をエイリアスまたは「委任ID」として利用できるようになります。HTMLに適切なOpenIDタグを挿入するか[ 14 ] 、 Yadisドキュメントを提供するだけで済みます[ 15 ] 。

OpenID 認証 2.0 (および一部の 1.1 実装) 以降、OpenID で使用できる識別子には URL と XRI の 2 種類があります。

XRI は、クロスドメインデジタルアイデンティティ専用に設計された新しい形式のインターネット識別子です。例えば、XRI にはi-nameとi-numberという 2 つの形式があり、通常は同義語として同時に登録されます。i-name はドメイン名のように再割り当て可能ですが、i-number は再割り当てされません。XRI i-name を OpenID 識別子として使用すると、直ちに同義の i-number（XRDS ドキュメントの CanonicalID 要素）に解決されます。この i-number が、証明書利用者によって保存される OpenID 識別子です。このようにして、再割り当て可能な DNS 名に基づく URL で起こり得るような、エンドユーザーの OpenID アイデンティティが他者に乗っ取られる事態から、ユーザーと証明書利用者の両方が保護されます。

OpenID財団

OpenID Foundation（OIDF）は、OpenIDコミュニティと技術の推進と強化に取り組んでいます。OIDFは、OpenIDの推進と保護を願う個人開発者、政府機関、企業で構成される非営利の国際標準化団体です。OpenID Foundationは2007年6月に設立され、開発者、ベンダー、ユーザーからなるオープンコミュニティを代表する公益信託組織として機能しています。OIDFは、OpenIDの普及とサポートに必要なインフラを提供し、コミュニティを支援しています。これには、知的財産と商標の管理、OpenIDの普及と世界的な参加の促進が含まれます。

人々

OpenID Foundationの取締役会には、6人のコミュニティ理事会メンバーと8人の企業理事会メンバーがいます。[ 16 ]

章

OIDFは、デジタルアイデンティティの普及とOpenIDのさらなる普及を促進するグローバル組織です。OIDFはメンバー支部の設立を奨励しています。メンバー支部は正式にOIDFの一員となり、それぞれの支部内で活動し、インターネットにおけるユーザー中心のアイデンティティのフレームワークとしてのOpenIDの開発と普及を支援しています。

知的財産および貢献契約

OIDFはOpenID仕様が自由に実装可能であることを保証するため、すべての貢献者に貢献契約への署名を義務付けています。この契約は、OIDFに共同仕様を公開するための著作権ライセンスを付与するとともに、特許非主張契約も含んでいます。この非主張契約では、貢献者はOpenID仕様の実装を理由に訴訟を起こさないことが規定されています。

米国におけるOpenIDの商標は、2008年3月にOpenID Foundationに譲渡されました。[ 17 ] OpenID Foundationが活動する以前はNetMesh Inc.によって登録されていました。[ 18 ] [ 19 ]ヨーロッパでは、2007年8月31日現在、OpenIDの商標はOpenID Europe Foundationに登録されています。[ 20 ]

OpenIDのロゴはランディ・「ydnar」・レディグによってデザインされました。彼は2005年にOpenID組織に権利を譲渡する計画を表明していました。[ 21 ]

OpenIDの最初の発表以来、公式サイトでは次のように述べられています。[ 22 ]

これを所有する人は誰もいません。誰もこれで金儲けしようとは思っていません。目標は、このゲームのすべての部分を可能な限り自由なライセンスの下でリリースすることです。そのため、プレイするのにお金もライセンスも登録も必要ありません。このようなものが存在することはコミュニティ全体に利益をもたらし、私たちは皆、コミュニティの一員なのです。

Sun Microsystems、VeriSign、そしてOpenIDに関与する複数の小規模企業は、OpenID 1.1仕様を対象とした特許非行使契約を締結しました。この契約では、各社はOpenID実装に対していかなる特許も行使しないこと、またOpenID実装者に対して特許を脅迫したり、行使したりする者に対しては、その約束を撤回することを規定しています。[ 23 ] [ 24 ]

安全

認証バグ

2012年3月、ある研究論文[ 25 ]で OpenID の一般的なセキュリティ問題が2件報告されました。どちらの問題も、攻撃者が被害者の証明書利用者アカウントにサインインすることを可能にしています。最初の問題については、OpenID と Google（OpenID のアイデンティティプロバイダ）が両方とも、その問題に対処するためのセキュリティ勧告を公開しました。[ 26 ] [ 27 ] Google の勧告には、「攻撃者は、ユーザーの電子メールアドレスを尋ねない OpenID リクエストを偽造し、署名されていない電子メールアドレスを IDP の応答に挿入する可能性があります。攻撃者がこの応答を、この属性が署名されていないことに気付かないウェブサイトに中継すると、ウェブサイトは攻撃者を任意のローカルアカウントにログインさせてしまう可能性があります」と記載されています。研究論文では、Yahoo! メール、smartsheet.com、Zoho、manymoon.com、diigo.comなど、多くの人気ウェブサイトで脆弱性が確認されていると主張しています。研究者は影響を受ける関係者に通知し、関係者は脆弱なコードを修正しました。

2つ目の問題については、論文では「データ型混同ロジックの欠陥」と名付けられており、攻撃者が被害者のRPアカウントにサインインすることも可能になります。当初、 GoogleとPayPalに脆弱性があることが確認されました。OpenIDはこの欠陥に関する脆弱性レポート[ 28 ]を公開しました。レポートによると、GoogleとPayPalはすでに修正を適用しており、他のOpenIDベンダーにも実装を確認するよう推奨しています。

フィッシング

一部の観察者は、OpenIDにはセキュリティ上の弱点があり、フィッシング攻撃に対して脆弱である可能性があると指摘しています。[ 29 ] [ 30 ] [ 31 ]例えば、悪意のある中継者がエンドユーザーを偽のアイデンティティプロバイダの認証ページに転送し、エンドユーザーに認証情報の入力を求める場合があります。認証情報の入力が完了すると、悪意のある者（この場合は偽の認証ページも管理している）は、エンドユーザーのアイデンティティプロバイダアカウントにアクセスし、そのエンドユーザーのOpenIDを使用して他のサービスにログインできるようになります。

フィッシング攻撃の可能性に対抗するため、一部のOpenIDプロバイダは、エンドユーザーがリライングパーティで認証を行う前に、そのプロバイダで認証を受けることを義務付けています。[ 32 ]これは、エンドユーザーがアイデンティティプロバイダのポリシーを知っていることを前提としています。2008年12月、OpenID Foundationはプロバイダ認証ポリシー拡張（PAPE）バージョン1.0を承認しました。この拡張により、「リライングパーティは、OpenIDプロバイダに対し、ユーザー認証時に特定の認証ポリシーを適用するよう要求することができ、OpenIDプロバイダはリライングパーティに対し、実際にどのポリシーが使用されたかを通知することができる」ようになりました。[ 33 ]

プライバシーと信頼の問題

OpenIDに関連するその他のセキュリティ上の問題としては、プライバシーの欠如や信頼の問題への対処の失敗などが挙げられます。[ 34 ]しかし、この問題はOpenIDに特有のものではなく、単にインターネットが一般的に使用されている状態です。

ただし、アイデンティティプロバイダーはOpenIDログインのログを取得します。つまり、いつどのウェブサイトにログインしたかが分かるため、サイト間のトラッキングが容易になります。また、OpenIDアカウントの侵害は、単一のサイトのアカウントの侵害よりも深刻なプライバシー侵害となる可能性があります。

安全でない接続での認証ハイジャック

TLS/SSLが使用されていない場合、認証スキームの最後のステップ、すなわちアイデンティティプロバイダから証明書利用者へのリダイレクトURLに、もう一つの重要な脆弱性が存在します。このリダイレクトの問題は、このURLを入手できれば（例えば、ネットワークをスニッフィングするなどして）、誰でもそれをリプレイして、被害者ユーザーとしてサイトにログインできるということです。一部のアイデンティティプロバイダは、ナンス（一度だけ使用される番号）を使用して、ユーザーが一度サイトにログインすれば、その後の試行はすべて失敗するようにしています。ナンスによる解決策は、ユーザーが最初にそのURLを使用する場合に有効です。しかし、ネットワークをスニッフィングしている高速攻撃者は、URLを入手してすぐにユーザーのTCP接続をリセットし（攻撃者はネットワークをスニッフィングしているため、必要なTCPシーケンス番号を知っているため）、前述のようにリプレイ攻撃を実行することができます。したがって、ナンスは受動的な攻撃者から保護するだけで、能動的な攻撃者によるリプレイ攻撃を防ぐことはできません。[ 35 ]認証プロセスでTLS/SSLを使用することで、このリスクを大幅に軽減できます。

これを言い換えると次のようになります。 

 IF (RP1とRP2の両方にボブがクライアントとして存在する) AND // 一般的なケース (ボブはRP1とRP2の両方で同じIDPを使用しています) AND // 一般的なケース (RP1 はクライアントとの接続を保護するために VPN/SSL/TLS を使用しません) // 防止可能! それから RP2はRP1を使ってボブになりすますのに十分な資格情報を入手することができる END-IF

秘密のリダイレクト

2014年5月1日、「 OAuth 2.0とOpenIDに関連する秘密のリダイレクト」と呼ばれるバグが公開されました。 [ 36 ] [ 37 ]これは、シンガポールの南洋理工大学物理数学学部の数学博士課程の学生である王静によって発見されました。[ 38 ] [ 39 ] [ 40 ]

OpenIDに関する発表は次のとおりです。「2014年5月に公表された『Covert Redirect』は、攻撃者がオープンリダイレクタを利用する事例です。これはよく知られた脅威であり、既知の予防手段も存在します。OpenID Connectプロトコルでは、この脆弱性を防ぐため、オープンリダイレクタを排除する厳格な対策を義務付けています。」[ 41 ]

これまでのところ、一般的な見解としては、Covert Redirectはそれほど悪くはないものの、依然として脅威であるということです。何が危険なのかを理解するには、Open Redirectとその悪用方法についての基本的な理解が必要です。[ 42 ]

パッチはすぐには提供されませんでした。41st Parameterの創設者、会長、最高イノベーション責任者であるオリ・アイゼン氏は、スー・マルケット・ポレンバ氏に次のように語りました。「分散システムにおいては、参加者が善意に基づいて正しい行動をとることを期待しています。OAuthやOpenIDのようなシステムの場合、分散環境があまりにも広範囲にわたるため、すべてのウェブサイトが近い将来にパッチを当てられると期待するのは無理があります。」[ 43 ]

歴史

オリジナルの OpenID 認証プロトコルは、2005 年 5 月に、人気のコミュニティ ウェブサイトLiveJournalの作成者であるBrad Fitzpatrick氏によって、 Six Apart 社で働いていたときに開発されました[ 44 ]。[ 45 ]当初は Yadis (「Yet another distributed identity system」の頭字語) と呼ばれていましたが、[ 46 ] Six Apart 社にプロジェクトで使用するためにopenid.netドメイン名が与えられたことから、OpenID と命名されました。 [ 47 ] OpenID サポートはすぐにLiveJournalと、同じく LiveJournalエンジンコミュニティのDeadJournalにブログ投稿のコメント用に実装され、デジタル ID コミュニティで急速に注目を集めました[ 48 ] [ 49 ] Web 開発者のJanRain は、OpenID の初期の支持者であり、OpenIDソフトウェア ライブラリを提供し、OpenID ベースのサービスを中心にビジネスを拡大していました。

6月下旬、OpenIDユーザーとエンタープライズソフトウェア企業NetMeshの開発者の間で議論が始まり、OpenIDとNetMeshの類似プロトコルである軽量アイデンティティ（LID）との相互運用性に関する協力関係が生まれました。この協力関係の直接的な成果として、OpenIDに元々使用されていた名称を採用したYadis発見プロトコルが誕生しました。新しいYadisは2005年10月24日に発表されました。[ 50 ]数日後の2005年インターネットアイデンティティワークショップでの議論の後、 XRI / i-names開発者がYadisプロジェクトに参加し、[ 51 ]プロトコルでの利用のために拡張可能リソース記述子シーケンス（XRDS ）形式を提供しました。 [ 52 ]

12月、Sxip Identityの開発者は、Simple Extensible Identity Protocol（SXIP）バージョン2.0の開発をLIDやOpenIDのようなURLベースのアイデンティティに移行することを発表した後、OpenID/Yadisコミュニティとの議論を開始しました[53]。[ 54 ] 2006年3月、JanRainはOpenID用のSimple Registration（SREG）拡張機能を開発し、基本的なプロファイル交換を可能にしました[ 55 ]そして4月にはOpenIDへの拡張機能を正式化する提案を提出しました。同月、OpenIDに完全なXRIサポートを組み込む作業も開始されました[ 56 ] 。 5月初旬頃、OpenIDの主要開発者であるDavid RecordonがSix Apartを離れ、VeriSignに加わり、デジタルアイデンティティとOpenID仕様のガイダンスにより重点的に取り組みました。[ 49 ] [ 57 ] 6月初旬までに、SXIP 2.0プロジェクトとOpenIDプロジェクトの主な相違点は、OpenIDで複数のペルソナをサポートするために、完全なアイデンティティURLではなく、アイデンティティプロバイダURLを提出することで合意したことで解消されました。これにより、拡張機能の追加とXRIサポートの進行中に、OpenIDは本格的なデジタルアイデンティティフレームワークへと進化しました。Recordon氏は次のように述べています。「私たちはOpenIDを、識別子、検出、認証、そしてその上にあるメッセージングサービスレイヤーを包含するフレームワークの包括的な枠組みと見ており、この全体を『OpenID 2.0』と呼んでいます。」[ 58 ] 7月下旬、SXIPは自社のDigital Identity Exchange (DIX)プロトコルをOpenIDに統合し始め、8月にはOpenID Attribute Exchange (AX)拡張の初期ドラフトを提出しました。2006年末には、ZDNetのオピニオン記事で、ユーザー、ウェブサイト運営者、起業家に向けてOpenIDの重要性が訴えられました。[ 59 ]

2007年1月31日、シマンテックは自社のIdentity Initiative製品およびサービスでOpenIDをサポートすると発表した。[ 60 ] 1週間後の2月6日、マイクロソフトはJanRain、Sxip、VeriSignと共同で、OpenIDとマイクロソフトのWindows CardSpaceデジタルアイデンティティプラットフォームとの相互運用性について協力し、特にOpenID向けのフィッシング耐性認証ソリューションの開発に注力すると発表した。この協力の一環として、マイクロソフトは将来のアイデンティティサーバー製品でOpenIDをサポートすることを約束し、JanRain、Sxip、VeriSignは将来のアイデンティティソリューションにマイクロソフトの情報カードプロファイルのサポートを追加することを約束した。[ 61 ] 2月中旬、AOLは実験的なOpenIDプロバイダーサービスがすべてのAOLおよびAOLインスタントメッセンジャー（AIM）アカウントで機能していると発表した。[ 62 ]

5月、サン・マイクロシステムズはOpenIDコミュニティとの協力を開始し、OpenIDプログラムを発表した。[ 63 ]また、OpenIDコミュニティと非主張契約を締結し、OpenIDの実装に対して自社の特許を一切主張しないことを誓約した。[ 23 ] 6月、OpenIDのリーダーシップは、オレゴン州に拠点を置く公益法人であるOpenID Foundationを設立し、OpenIDのブランドと資産を管理した。[ 64 ]同月、ベルギーで独立したOpenID Europe FoundationがSnorri Giorgettiによって設立された。 [ 65 ] 12月初旬までに、プロトコルの主要貢献者による非主張契約がまとめられ、最終的なOpenID Authentication 2.0とOpenID Attribute Exchange 1.0の仕様が12月5日に批准された。[ 66 ]

2008年1月中旬、Yahoo! はプロバイダーおよびリライングパーティの両方として OpenID 2.0 の初期サポートを発表し、月末までにプロバイダー サービスをリリースしました。[ 67 ] 2月初旬、Google、IBM、Microsoft、VeriSign、Yahoo! が OpenID Foundation の役員会メンバーに加わりました。[ 68 ] 5月初旬頃、SourceForge, Inc. は、大手オープンソース ソフトウェア開発 Web サイトSourceForge.netに OpenID プロバイダーおよびリライング パーティのサポートを導入しました。[ 69 ] 7月下旬、人気のソーシャル ネットワーク サービスのMySpace は、プロバイダーとして OpenID をサポートすると発表しました。[ 70 ] 10月下旬、Google は OpenID プロバイダーとしてのサポートを開始し、Microsoft はWindows Live IDでOpenID をサポートすると発表しました。[ 71 ] 11月、JanRain は、OpenID オープンソース ライブラリをインストール、統合、構成することなく、Web サイトが登録およびログインに OpenID を受け入れることができる無料のホスト サービス RPX Basic を発表しました。[ 72 ]

2009年1月、PayPalはOpenID Foundationの法人会員として加盟し、その後まもなく2月にFacebookも加盟しました。OpenID Foundationは執行委員会を結成し、ドン・ティボーをエグゼクティブ・ディレクターに任命しました。3月には、MySpaceが既に発表していたOpenIDプロバイダーサービスを開始し、MySpaceユーザーはMySpaceのURLをOpenIDとして利用できるようになりました。5月にはFacebookがRelying Party機能を開始し、[ 73 ] [ 74 ]、ユーザーは自動ログインに対応したOpenIDアカウント（Googleなど）を使用してFacebookにログインできるようになりました。[ 75 ]

2013年9月、ジャンレインはMyOpenID.comが2014年2月1日に閉鎖されると発表した。円グラフによると、2013年第2四半期の時点でFacebookとGoogleがソーシャルログイン市場を独占していた。[ 76 ] Facebookはその後OpenIDから撤退し、もはやスポンサーではなく、取締役会にも代表を置かず、OpenIDログインも許可していない。[ 16 ] [ 77 ]

2016年5月、シマンテックはpip.verisignlabs.com OpenID個人IDポータルサービスの提供を中止すると発表しました。[ 78 ] [ 79 ]

2018年3月、Stack OverflowはOpenIDのサポート終了を発表しました。その理由は、OpenIDの利用率がコストに見合わないためです。発表の中で、ユーザーの利用状況から判断すると、Facebook、Google、そしてメールアドレスとパスワードによるアカウント認証を強く好んでいることが述べられました。[ 80 ]

OpenIDとOAuthを使用した疑似認証

OpenIDは、単一のユーザー認証情報を使用して複数のサイトにアクセスする方法です。一方、OAuthは、あるサイトが別のサイトにあるユーザーアカウントに関連する情報にアクセスし、使用することを承認する仕組みです。OAuthは認証プロトコルではありませんが、認証プロトコルの一部として使用できます。

アプリケーションにアクセスするユーザーのコンテキストでの認証は、現在のユーザーが誰であるか、およびそのユーザーがアプリケーションに存在するかどうかをアプリケーションに伝えます。[...] 認証はユーザーとアプリケーションでの存在に関するものであり、インターネット規模の認証プロトコルは、ネットワークとセキュリティの境界を越えてこれを実行できる必要があります。

しかし、OAuthはアプリケーションにそのような情報は一切伝えません。OAuthはユーザーについて全く何も言わず、ユーザーがどのように存在を証明したか、あるいはまだそこにいるかどうかさえも伝えません。OAuthクライアント側から見れば、トークンを要求し、トークンを取得し、最終的にそのトークンを使って何らかのAPIにアクセスしたというだけです。誰がアプリケーションを承認したのか、そもそもユーザーがそこにいたのかどうかさえも全く知りません。実際、OAuthの目的の多くは、クライアントとアクセス対象のリソース間の接続にユーザーが存在しない状況で使用できるように、この委任アクセスを提供することにあります。これはクライアント認証には最適ですが、ユーザーがそこにいるかどうか（そして誰なのか）を判断することが重要な認証には非常に不向きです。[ 81 ]

以下の図は、認証におけるOpenIDとOAuthの違いを示しています。OpenIDの場合、プロセスはアプリケーションがユーザーにID（通常はOpenID URI）を尋ねることから始まります。一方、OAuthの場合は、アプリケーションがユーザーに代わってAPIにアクセス（アクセス）するために、アクセスが制限されたOAuthトークン（バレットキー）を直接要求します。ユーザーがアクセスを許可した場合、アプリケーションはAPIを使用してプロファイル（ID）を確立するための一意の識別子を取得できます。

OpenID と OAuth を使用した疑似認証

疑似認証に対する攻撃

OpenID は、認証に OAuth を悪用するユーザーに対する以下の攻撃を防ぐ暗号化検証メカニズムを提供します。

注意すべきは、バレットキーはユーザーを何らかの形で記述するものではなく、ある家（必ずしもユーザーの家である必要はなく、単に鍵を持っているだけ）への限定的なアクセス権のみを提供するという点です。したがって、もしキーが侵害された場合（ユーザーが悪意を持って他人の家の鍵を盗んだ場合）、ユーザーは認証を要求したアプリケーションに対して家の所有者になりすますことができます。信頼チェーンのどの時点でもキーが侵害された場合、悪意のあるユーザーがそれを傍受し、OAuth2を使用して同じOAuth認可サーバーに対する疑似認証を行うアプリケーションでユーザーXになりすますために使用することができます。逆に、公証された手紙にはユーザーの署名が含まれており、要求元のアプリケーションはそれをユーザーに対して照合できるため、この攻撃は実行不可能です。 [ 82 ]

手紙の検証

手紙は公開鍵暗号を使用して認証されます。

  • 要求元のアプリケーションは暗号化公開キーをユーザーに提供し、ユーザーはそれを認証サーバーに提供します。
  • 認証サーバーは、アプリケーションの公開キーを使用して、チャレンジレスポンス用のユーザーが知っている秘密 (パスフレーズなど) の一方向ハッシュに対応する暗号化キーを含むドキュメントを暗号化します。
  • ユーザーは暗号化されたドキュメントをアプリケーションに返し、アプリケーションはそれを復号化します。
  • アプリケーションは受信した暗号化キーを使用してランダムなフレーズを暗号化し、ユーザーにも同じことを行うように要求して結果を比較します。結果が一致すれば、ユーザーは本物です。

OpenIDコネクト（OIDC）

2014年2月にOpenID Foundationによって公開された[ 83 ] OpenID Connect（OIDC）は、OpenID技術の第3世代です。OAuth 2.0認可フレームワークの上位に位置する認証レイヤーです[ 84 ] 。これにより、コンピューティングクライアントは、認可サーバーによって実行される認証に基づいてエンドユーザーの身元を検証し、相互運用性のあるRESTのような方法でエンドユーザーの基本プロファイル情報を取得できます。技術的には、OpenID ConnectはJSONをデータ形式として用いるRESTful HTTP APIを規定しています。

OpenID Connectは、Webベース、モバイル、JavaScriptクライアントなど、様々な関係者が認証済みセッションやエンドユーザーに関する情報を要求・受信することを可能にします。OpenID Connect仕様は拡張可能で、IDデータの暗号化、OpenIDプロバイダーの検出、セッション管理といったオプション機能をサポートしています。

参照

参考文献

  1. ^ a b c d Eldon, Eric (2009年4月14日). 「シングルサインオンサービスOpenIDの利用が増加」 . venturebeat.com. 2018年4月2日時点のオリジナルよりアーカイブ。 2009年4月25日閲覧。
  2. ^ 「OpenIDとは？」 2007年10月8日。 2014年6月14日時点のオリジナルよりアーカイブ。 2014年6月19日閲覧。
  3. ^ 「OpenID Authentication 2.0 specification – Final」。2011年10月22日時点のオリジナルよりアーカイブ。2011年10月24日閲覧。
  4. ^ 「OpenID Attribute Exchange 1.0 – Final」。2017年11月20日時点のオリジナルよりアーカイブ。2011年10月24日閲覧。
  5. ^ 「OpenID Authentication 2.0 - Final」 2007年12月5日. 2011年10月22日時点のオリジナルよりアーカイブ。 2014年5月18日閲覧。
  6. ^ 「OpenID使用状況統計」。2016年4月4日時点のオリジナルよりアーカイブ。2016年4月1日閲覧。
  7. ^ bashburn, bill (2008年4月22日). 「BBCがOpenID Foundationに参加」 . OpenID - インターネット・アイデンティティ・レイヤー. 2008年10月16日時点のオリジナルよりアーカイブ。 2008年10月29日閲覧。
  8. ^ 「技術リーダーがOpenID Foundationに参加し、Web上のオープンアイデンティティ管理を促進」 2008年2月7日。2008年2月10日時点のオリジナルよりアーカイブ。
  9. ^ 「PayPal Access Uses OpenID 2.0」。OpenID - The Internet Identity Layer。OpenID ·。2011年10月19日。 2014年6月22日時点のオリジナルよりアーカイブ。 2014年6月19日閲覧。
  10. ^ “Steamコミュニティ::Steam Web APIドキュメント” . 2012年2月10日時点のオリジナルよりアーカイブ。2012年2月10日閲覧。
  11. ^ Perez, Juan Carlos (2008年12月4日). 「FacebookとGoogle、全ユーザー向けのデータポータビリティプログラムを開始」 . Network World, Inc. 2014年6月22日時点のオリジナルよりアーカイブ。 2014年6月19日閲覧。
  12. ^ 「Bloggerの春の大掃除の季節です」 Bloggerチーム。2018年8月2日時点のオリジナルよりアーカイブ。2019年9月10日閲覧。
  13. ^ Deeptha, R.; Mukesh, Rajeswari (2018年9月1日). 「OpenID Connectのミッションクリティカルアプリケーションへの拡張」 .サイバネティクスと情報技術. 18 (3): 93– 110. doi : 10.2478/cait-2018-0041 .
  14. ^ 「OpenID Authentication 1.1#Delegation」。2017年11月18日時点のオリジナルよりアーカイブ。2009年6月30日閲覧。
  15. ^ Paul Tarjan. 「Yadisを使ったOpenIDの簡単な委任」 。 2009年7月4日時点のオリジナルよりアーカイブ。 2009年6月30日閲覧。
  16. ^ a b「リーダーシップ」 . openID Foundation. 2014年6月24日時点のオリジナルよりアーカイブ。 2014年6月19日閲覧。
  17. ^ 「商標譲渡、シリアル番号：78899244」。米国特許商標庁。2008年5月6日。2013年10月10日時点のオリジナルよりアーカイブ。2008年5月19日閲覧。Exec Dt: 03/27/2008
  18. ^ 「最新のステータス情報」。米国特許商標庁。2006年3月27日。2011年5月14日時点のオリジナルよりアーカイブ。2008年3月20日閲覧。
  19. ^ 「NetMesh: 会社情報 / 経営」NetMesh . 2007年8月30日時点のオリジナルよりアーカイブ。2008年3月20日閲覧。
  20. ^ 「OpenID Europe 商標およびロゴポリシー」OpenID Europe Foundation . 2008年3月9日時点のオリジナルよりアーカイブ。 2008年3月20日閲覧。
  21. ^ Reddig, Randy (2005年6月29日). 「OpenIDロゴ」 . Danga Interactive . 2008年2月14日時点のオリジナルよりアーカイブ。2008年3月20日閲覧。
  22. ^ Fitzpatrick, Brad (2009年8月10日). 「知的財産」 . 2009年10月11日時点のオリジナルよりアーカイブ。2009年10月13日閲覧。
  23. ^ a b「Sun OpenID: 非アサーション契約」 . Sun Microsystems . 2008年3月20日閲覧。
  24. ^ 「VeriSignのOpenID非主張特許契約」VeriSign . 2008年4月15日時点のオリジナルよりアーカイブ。2008年3月20日閲覧。
  25. ^ Rui Wang、Shuo Chen、XiaoFeng Wang (2012年5月). 「FacebookとGoogle経由であなたのアカウントにサインする：商用展開されているシングルサインオンWebサービスのトラフィックガイドによるセキュリティ調査」 . 2016年4月13日時点のオリジナルよりアーカイブ。 2012年3月9日閲覧。
  26. ^ 「Attribute Exchange Security Alert」 2011年5月5日. 2017年7月31日時点のオリジナルよりアーカイブ。 2012年3月9日閲覧。
  27. ^ 「OpenID Attribute Exchange を使用するウェブサイトへのセキュリティ勧告」 2011年5月5日。2011年12月24日時点のオリジナルよりアーカイブ。2012年3月9日閲覧。
  28. ^ 「脆弱性レポート：データの混乱」 OpenID - インターネットアイデンティティレイヤー2012年3月15日. 2019年9月5日時点のオリジナルよりアーカイブ。2012年3月15日閲覧。
  29. ^ Crowley, Paul (2005年6月1日). 「OpenIDに対するフィッシング攻撃」 . Danga Interactive . 2008年10月10日時点のオリジナルよりアーカイブ。 2008年3月20日閲覧。
  30. ^ Anderson, Tim (2007年3月5日). 「OpenIDは依然として悪用される可能性がある」 . IT Week. 2008年7月4日時点のオリジナルよりアーカイブ。2007年3月13日閲覧。
  31. ^ Slot, Marco. 「OpenIDフィッシング初心者ガイド」。2007年8月4日時点のオリジナルよりアーカイブ。2007年7月31日閲覧。
  32. ^ 「Verisign PIP FAQ」 。 2008年11月13日時点のオリジナルよりアーカイブ。2008年11月13日閲覧。
  33. ^ Jones, Mike (2008年12月31日). 「PAPEがOpenID仕様として承認」 . OpenID Foundation. 2009年1月1日時点のオリジナルよりアーカイブ。 2009年1月2日閲覧。
  34. ^ Stefan Brands (2007年8月22日). 「OpenIDの問題点」 . 2011年5月16日時点のオリジナルよりアーカイブ。2010年12月12日閲覧。(The Identity Corner (www.idcorner.org/?p=161) に最初に掲載されました)
  35. ^ Tsyrklevich, Eugene. 「インターネットにおけるシングルサインオン：セキュリティのストーリー」(PDF) . Blackhat USA. 2012年1月12日時点のオリジナルよりアーカイブ(PDF) . 2012年4月19日閲覧。
  36. ^ 「OAuthとOpenIDに深刻なセキュリティ欠陥が発見される」 CNET、2014年5月2日。2015年11月2日時点のオリジナルよりアーカイブ。 2014年11月10日閲覧。
  37. ^ "Covert Redirect" . Tetraph. 2014年5月1日. 2016年3月10日時点のオリジナルよりアーカイブ。 2014年11月10日閲覧。
  38. ^ 「Facebook、Googleユーザーが新たなセキュリティ欠陥に脅かされる」 Yahoo、2014年5月2日。2019年7月25日時点のオリジナルよりアーカイブ。 2014年11月10日閲覧。
  39. ^ 「OAuthとOpenIDに悪質な隠蔽リダイレクト脆弱性が発見される」 The Hacker News、2014年5月3日。2014年11月8日時点のオリジナルよりアーカイブ。 2014年11月10日閲覧。
  40. ^ 「数学の学生がOAuthとOpenIDのセキュリティ脆弱性を発見」 Tech Xplore、2014年5月3日。2014年12月4日時点のオリジナルよりアーカイブ。 2014年11月10日閲覧。
  41. ^ 「Covert Redirect」 . OpenID - The Internet Identity Layer . OpenID. 2014年5月15日. 2014年10月20日時点のオリジナルよりアーカイブ。 2014年11月10日閲覧。
  42. ^ "「『Covert Redirect』脆弱性がOAuth 2.0、OpenIDに影響を与える」 SC Magazine、2014年5月2日。 2014年11月10日閲覧。
  43. ^ 「隠蔽リダイレクトから学ぶべき教訓」 41st Parameter、2014年5月5日。 2014年11月10日閲覧。
  44. ^ Fitzpatrick, Brad (2005年5月16日). 「Distributed Identity: Yadis」 . LiveJournal . 2006年5月4日時点のオリジナルよりアーカイブ。2008年3月20日閲覧。
  45. ^ Waters, John K (2007年12月1日). 「OpenID Updates Identity Spec」 . Redmond Developer News . 2008年2月8日時点のオリジナルよりアーカイブ。 2008年3月20日閲覧。
  46. ^ 「用語集」。LiveJournal Server: 技術情報。2009年9月30日時点のオリジナルよりアーカイブ。2009年10月13日閲覧。
  47. ^ Lehn, David I. (2005年5月18日). 「2005年5月18日」 . dlehnのAdvogatoブログ. Advogato.オリジナルより2010年12月21日アーカイブ. 2009年10月13日閲覧。彼らは名前を探していて、私が提案する直前にopenid.netについてメールで連絡をくれました。そこで、新しく改良されたOpenIDプロジェクトのために、その名前を彼らに提供しました。
  48. ^ 「OpenID: 実際に分散されたアイデンティティシステム」 2005年9月24日。 2005年9月24日時点のオリジナルよりアーカイブ。2008年3月20日閲覧。
  49. ^ a b Fitzpatrick, Brad (2006年5月30日). 「brad's life – OpenID and SixApart」 . LiveJournal . 2007年4月25日時点のオリジナルよりアーカイブ。2008年3月20日閲覧。
  50. ^ Recordon, David (2005年12月24日). 「YADISの発表…再び」 . Danga Interactive . 2008年9月5日時点のオリジナルよりアーカイブ。 2008年3月20日閲覧。
  51. ^ Reed, Dummond (2005年12月31日). 「YADISを新しいソフトウェアなしで実装する」 . Danga Interactive . 2008年9月5日時点のオリジナルよりアーカイブ。2008年3月20日閲覧。
  52. ^ Reed, Drummond (2008年11月30日). 「XRD Begins」 . Equals Drummond . 2008年12月20日時点のオリジナルよりアーカイブ。2009年1月5日閲覧。
  53. ^ Hardt, Dick (2005年12月18日). 「SxipのYADISに関する懸念」 . Danga Interactive . 2008年10月15日時点のオリジナルよりアーカイブ。2008年3月20日閲覧。
  54. ^ Hardt, Dick (2005年12月10日). 「SXIP 2.0 Teaser」 . Identity 2.0 . 2007年8月14日時点のオリジナルよりアーカイブ。2008年3月20日閲覧。
  55. ^ Hoyt, Josh (2006年3月15日). 「OpenID + Simple Registration Information Exchange」 . Danga Interactive . 2008年10月11日時点のオリジナルよりアーカイブ。2008年3月20日閲覧。
  56. ^ Grey, Victor (2006年4月2日). 「OpenID向けXRI（i-name）プロファイルの提案」 . Danga Interactive . 2008年3月19日時点のオリジナルよりアーカイブ。2008年3月20日閲覧。
  57. ^ Recordon, David (2006年4月29日). "Movin' On..." LiveJournal . 2006年10月20日時点のオリジナルよりアーカイブ。 2008年3月20日閲覧。
  58. ^ Recordon, David (2006年6月16日). 「Moving OpenID Forward」 . Danga Interactive . 2008年5月22日時点のオリジナルよりアーカイブ。2008年5月19日閲覧。
  59. ^ Becker, Phil (2006年12月4日). 「OpenIDのケース」 . ZDNet . 2025年5月4日時点のオリジナルよりアーカイブ。2010年12月12日閲覧。
  60. ^ 「Symantec、DEMO 07カンファレンスでSecurity 2.0 Identity Initiativeを発表」Symantec 、2007年1月31日。2007年2月9日時点のオリジナルよりアーカイブ。 2008年3月20日閲覧。
  61. ^ Graves, Michael (2007年2月6日). 「VeriSign、Microsoft、パートナーがOpenID + Cardspaceで協力」 . VeriSign . 2008年5月3日時点のオリジナルよりアーカイブ。 2008年3月20日閲覧。
  62. ^ Panzer, John (2007年2月16日). 「AOLと6300万のOpenID」 . AOL Developer Network . 2008年5月11日時点のオリジナルよりアーカイブ。2008年3月20日閲覧。
  63. ^ 「Sun MicrosystemsがOpenIDプログラムを発表」 PR Newswire 2007年5月7日。2008年5月9日時点のオリジナルよりアーカイブ。 2008年3月20日閲覧。
  64. ^ OpenID Board of Directors (2007年6月1日). 「OpenID Foundation」 . 2017年11月23日時点のオリジナルよりアーカイブ。2008年3月20日閲覧。
  65. ^ “OpenID Europe Foundation” . 2008年4月15日時点のオリジナルよりアーカイブ。2008年4月4日閲覧。
  66. ^ 「OpenID 2.0...ついに！」OpenID Foundation . 2007年12月5日. 2008年4月30日時点のオリジナルよりアーカイブ。 2008年3月20日閲覧。
  67. ^ 「Yahoo!がOpenIDのサポートを発表。ユーザーはYahoo! IDで複数のインターネットサイトにアクセス可能」 Yahoo! 2008年1月17日。 2008年3月4日時点のオリジナルよりアーカイブ。 2008年3月20日閲覧。
  68. ^ 「技術リーダーがOpenID Foundationに参加し、Web上のオープンアイデンティティ管理を促進」OpenID Foundation Marketwire 2008年2月7日。2008年2月15日時点のオリジナルよりアーカイブ。 2008年3月20日閲覧。
  69. ^ 「SourceForgeがOpenIDテクノロジーを実装」（プレスリリース）SourceForge, Inc. 2008年5月7日。2008年5月13日時点のオリジナルよりアーカイブ。2008年5月21日閲覧。
  70. ^ 「MySpaceがOpenIDのサポートを発表し、新たなデータ可用性実装を導入」 Business Wire、MySpace、2008年7月22日、p. 2。2011年5月14日時点のオリジナルよりアーカイブ。 2008年7月23日閲覧。
  71. ^ 「MicrosoftとGoogleがOpenIDのサポートを発表」。OpenID - インターネットアイデンティティレイヤー。OpenID Foundation。2008年10月30日。2008年12月18日時点のオリジナルよりアーカイブ。 2009年1月2日閲覧。
  72. ^ 「JanRain、業界をリードするOpenIDソリューションの無料版をリリース」（プレスリリース）JanRain, Inc. 2008年11月14日。2008年12月18日時点のオリジナルよりアーカイブ。 2008年11月14日閲覧。
  73. ^ “Facebook Developers | Facebook Developers News” . Developers.facebook.com. 2009年5月18日. 2009年12月23日時点のオリジナルよりアーカイブ。 2009年7月28日閲覧。
  74. ^ 「FacebookがGoogleアカウントでのログインに対応」 Pocket-lint.com、2009年5月19日。2009年5月22日時点のオリジナルよりアーカイブ。 2009年7月28日閲覧。
  75. ^ 「OpenID Requirements – Facebook Developer Wiki」 Wiki.developers.facebook.com. 2009年6月26日. 2009年12月23日時点のオリジナルよりアーカイブ。 2009年7月28日閲覧。
  76. ^ Kane, Zee M (2013年9月4日). 「MyOpenIDが閉鎖へ。2014年2月1日に廃止予定」The Next Web . 2013年9月7日時点のオリジナルよりアーカイブ。 2013年9月5日閲覧。
  77. ^ 「OpenID スポンサーメンバー」 2009年10月7日. 2014年4月17日閲覧。
  78. ^ 「シマンテック個人識別ポータルのバナーに、2016年9月12日にサービスが廃止されることが表示されている」 。 2016年6月11日時点のオリジナルよりアーカイブ。 2016年5月17日閲覧。
  79. ^ 「シマンテックはGoogleであることに失敗しているのか？」 2016年5月7日。2016年6月2日時点のオリジナルよりアーカイブ。2016年5月17日閲覧。
  80. ^ “OpenIDのサポートは2018年7月25日に終了しました” . 2018年3月7日時点のオリジナルよりアーカイブ。2018年3月6日閲覧。
  81. ^ 「OAuth 2.0によるユーザー認証」 OAuth.net 2015年11月19日時点のオリジナルよりアーカイブ。2015年3月19日閲覧。
  82. ^ 「認証にプレーンOAuth2を使用するのはなぜ悪い考えなのか？」 Information Security Stack Exchange。2018年7月7日時点のオリジナルよりアーカイブ。 2018年7月7日閲覧。
  83. ^ 「Final OpenID Connect Core 1.0 - Appendix C. Notices」 . 2014年. 2024年3月14日時点のオリジナルよりアーカイブ。 2024年3月14日閲覧。
  84. ^ 「OpenID Connect FAQ and Q&A」 . 2014年2月20日. 2014年8月23日時点のオリジナルよりアーカイブ。 2014年8月25日閲覧。
「 https://en.wikipedia.org/w/index.php?title=OpenID&oldid=1322836047#OpenID_Connect_(OIDC)」から取得