オープンID

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

OpenID 標準は、アイデンティティ プロバイダーと OpenID アクセプタ (「依存当事者」) の間で行われる必要がある通信のフレームワークを提供します。^[3]標準の拡張機能 (OpenID 属性交換) により、名前や性別などのユーザー属性を OpenID アイデンティティ プロバイダーから依存当事者に転送できます (各依存当事者は、要件に応じて異なる属性セットを要求する場合があります)。^[4] OpenID プロトコルは、ユーザーの ID を認証するために中央機関に依存しません。さらに、サービスも 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 は、ユーザーが単一の認証情報セットを使用して複数の Web サイトで認証できるようにする分散認証プロトコルです。これにより、Web サイトごとに個別のユーザー名とパスワードを使用する必要がなくなります。OpenID は、アイデンティティ プロバイダー (IDP) を使用してユーザーを認証し、ID プロバイダーはユーザーに一意の識別子 (OpenID と呼ばれる) を提供します。この識別子は、OpenID をサポートする任意の Web サイトでユーザーを認証するために使用できます。

ユーザーが OpenID 認証をサポートする Web サイトにアクセスすると、Web サイトはユーザーをユーザーが選択した IDP にリダイレクトします。次に、IDP はユーザーに認証を求めます (ユーザー名とパスワードの入力など)。ユーザーが認証されると、IDP は OpenID を生成し、Web サイトに送り返します。Web サイトは、実際の資格情報を知ることなく、この OpenID を使用してユーザーを認証できます。

OpenIDは、HTTP、HTML、XMLなど、いくつかの既存の標準規格に基づいて構築されています。OpenIDは、ウェブサイトが特定のOpenIDに関連付けられたIDPを見つけることができる検出メカニズムや、フィッシングやその他の攻撃から保護するためのセキュリティメカニズムなど、さまざまなテクノロジーに依存しています。^[13]

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

OpenID は、Google、Yahoo!、PayPal など、多くの大規模な Web サイトやサービス プロバイダーで広く採用されています。このプロトコルは、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 プロバイダーは (オプションで)共有シークレットを確立します。これは関連ハンドルによって参照され、依存パーティはそれを保存します。checkid_setupモードを使用する場合、依存パーティはエンド ユーザーのユーザー エージェントを OpenID プロバイダーにリダイレクトし、エンド ユーザーが OpenID プロバイダーで直接認証できるようにします。

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

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

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

OpenID が検証されると、認証は成功したとみなされ、エンド ユーザーは指定された OpenID (例alice.openid.example.org) で指定された ID を使用して依存パーティにログインしたとみなされます。依存パーティは通常、エンド ユーザーの OpenID をエンド ユーザーのその他のセッション情報とともに保存します。

OpenID 対応の Web サイトにログインするために使用できるOpenID 対応のURL を取得するには、ユーザーはアイデンティティ プロバイダーに OpenID 識別子を登録します。アイデンティティ プロバイダーは、OpenID 認証サービスで自動的に構成される URL (通常は第 3 レベル ドメイン、例: username.example.com) を登録する機能を提供します。

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

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

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

OpenID Foundation (OIDF) は、OpenID コミュニティとテクノロジの促進と強化を行っています。OIDF は、OpenID の促進と保護を希望する個々の開発者、政府機関、企業で構成される非営利の国際標準開発組織です。OpenID Foundation は 2007 年 6 月に設立され、開発者、ベンダー、ユーザーのオープン コミュニティを代表する公的信託組織として機能しています。OIDF は、OpenID の採用の促進とサポートに必要なインフラストラクチャと支援を提供することでコミュニティを支援しています。これには、知的財産と商標の管理、OpenID の普及と世界的な参加の促進が含まれます。

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

OIDF は、デジタル ID を促進し、OpenID のさらなる採用を奨励するグローバル組織であり、メンバー チャプターの設立を奨励しています。メンバー チャプターは正式に Foundation の一部であり、独自の構成内で活動して、インターネット上のユーザー中心の ID のフレームワークとしての OpenID の開発と採用をサポートしています。

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

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

OpenIDのロゴは、2005年にOpenID組織に権利を譲渡する計画を表明していたRandy "ydnar" Reddigによってデザインされました。^[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! Mail、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 ログインのログを取得します。アイデンティティ プロバイダーは、いつどの Web サイトにログインしたかを把握しているため、サイト間の追跡がはるかに容易になります。また、侵害された OpenID アカウントは、単一のサイトのアカウントよりもプライバシーの侵害が深刻になる可能性があります。

TLS/SSL が使用されていない場合、認証スキームの最後のステップ、つまりアイデンティティ プロバイダーから依存パーティへのリダイレクト URL にもう 1 つの重要な脆弱性が存在します。このリダイレクトの問題は、この URL を取得できる人 (たとえば、回線をスニッフィングするなど) は誰でもそれを再生して、被害者ユーザーとしてサイトにログインできるということです。一部のアイデンティティ プロバイダーは、ユーザーがサイトに 1 回ログインし、その後の試行がすべて失敗することを可能にするために、ナンス(1 回だけ使用される番号) を使用します。ナンス ソリューションは、ユーザーが最初に URL を使用する場合に機能します。ただし、回線をスニッフィングしている高速攻撃者は、URL を取得してユーザーの TCP 接続をすぐにリセットし (攻撃者は回線をスニッフィングしており、必要な TCP シーケンス番号を知っているため)、上記のようにリプレイ攻撃を実行できます。したがって、ナンスは受動的な攻撃者から保護するだけで、能動的な攻撃者がリプレイ攻撃を実行するのを防ぐことはできません。^[35]認証プロセスで TLS/SSL を使用すると、このリスクを大幅に軽減できます。

これは次のように言い換えることができます。

  IF (RP1 と RP2 の両方に Bob がクライアントとして存在する) 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 distribution 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プロジェクトの主な違いは、完全なアイデンティティURLではなくアイデンティティプロバイダーURLを送信することでOpenIDで複数のペルソナをサポートするという合意により解決されました。これに加え、拡張機能の追加と XRI サポートの進行中に、OpenID は本格的なデジタル ID フレームワークへと進化しました。Recordon 氏は「OpenID は、識別子、検出、認証、およびメッセージング サービス レイヤーのレイヤーを網羅するフレームワークの包括的なものであると考えています。この全体は、いわば「OpenID 2.0」と呼ばれています。^[58] 7 月下旬、Sxip は自社の Digital Identity Exchange (DIX) プロトコルを OpenID に統合し始め、8 月に OpenID Attribute Exchange (AX) 拡張機能の初期ドラフトを提出しました。2006 年後半、ZDNet の意見記事で、ユーザー、Web サイト運営者、起業家に OpenID のメリットが説明されました。^[59]

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

5月、サン・マイクロシステムズはOpenIDコミュニティとの協力を開始し、OpenIDプログラムを発表し^[63]、OpenIDコミュニティと非主張契約を結び、OpenIDの実装に対して特許を主張しないことを誓約しました。^[23] 6月、OpenIDのリーダーシップは、OpenIDブランドと資産を管理するオレゴン州を拠点とする公益法人であるOpenID Foundationを設立しました。 ^[64]同月、ベルギーでSnorri Giorgettiによって独立したOpenID Europe Foundationが設立されました^[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 は、Web サイトが OpenID オープン ソース ライブラリをインストール、統合、構成することなく、登録およびログインに OpenID を受け入れることができる無料のホスト サービス RPX Basic を発表しました。^[72]

2009年1月、PayPalがOpenID Foundationに法人会員として参加し、2月にはFacebookもそれに続きました。OpenID Foundationは実行委員会を結成し、ドン・ティボーをエグゼクティブ・ディレクターに任命しました。3月、MySpaceは以前発表していたOpenIDプロバイダーサービスを開始し、すべてのMySpaceユーザーがMySpace URLをOpenIDとして使用できるようになりました。5月、Facebookはリライング・パーティ機能を開始し、^{[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のサポートを終了すると発表しました。発表では、アクティビティに基づいて、ユーザーはFacebook、Google、および電子メール/パスワードベースのアカウント認証を強く好んでいると述べられました。^[80]

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

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

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

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

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

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

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

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

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

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

• 公式サイト