経緯

OpenID2.0は開発を終了しているため、深刻な影響を及ぼすセキュリティホールが発見されても対応することが出来ません。
OpenID2.0からOpenID Connectへ認証基盤を移すことでセキュリティを維持することが出来ます。

基本概念のおさらい

本記事の目的はOpenID2.0とOpenID Connectの違いを理解できることとします。

認証(認可)

認証(認可)はユーザーごとに特定データへのアクセスを許すかどうかを決めるために実装されます。
これにより、他人の情報にアクセスできなく、他人が自分の情報にアクセスすることを防げます。
認証と認可は本来別の意味で使用されますが、大まかな流れの説明をしたいため説明は省略します。
認証にはID/PASS(クレデンシャル情報と言われます)などをコンテンツプロパイダ(認証を行う鯖、以下CP)が持ち判定する内部認証と
外部の認証基盤(Identity Provider、以下IdP)を使用して判定結果を貰う外部認証があります。
(内部認証は正式な用語ではないです)

AさんがCPにアクセスしてID-PASSを入力してログインできるのが内部認証です。
AさんがCPにアクセスした際に、CPがIdPに確認を取るのが外部認証です。
外部認証の例は、
AさんがCPでとあるキャリアのアカウントで決済を使用したい場合、
CPはAさんがそのキャリアと契約しているのかをIdPに判定してもらう時などです。

⭐️外部認証が内部認証と比較した際に優れているとされるのは以下の点です。

外部サービスのユーザー(ユーザー数●●●万人)をそのまま自サービスに持ち込める点
ユーザーがID-PASSを忘れてしまうことによる利用者のドロップ率の低減
外部サービスで認証し、不正ユーザーなどはロックされるためセキュリティの担保
IdPごとに独自の登録手順を踏むものの実装自体は簡単

プロトコル

CP-IdP間での認証(認可)のやりとり順序(処理手順)に対して標準化された手法というものが存在しています。
このやりとり順序をプロトコルといい、認証プロトコルとして標準化された手法には
「OAuth 2.0」、「OpenID Connect」、「FIDO 2.0」、「SAML 2.0」などがあります。
今回はOpenIDの説明に留めます。

OpenID

詳細な情報はこちらのドキュメントをご覧ください
https://www.openid.or.jp/document/

OpenID2.0は下記の性質のプロトコルです。

あるユーザが認証された旨の情報、認証をどのように行ったかの情報、当該ユーザの属性情報を、要求元であるWebサイトに対して、提供元となるアイデンティティ・プロバイダが転送するプロトコルである
(引用:https://ja.wikipedia.org/wiki/OpenID_Authentication_2.0)

最近の動き(と言っても古いですが。。。)は下記になります。

2008年1月30日 Yahoo JAPANが対応「Yahoo! Japan ID」でOpenID対応サイトが利用可能に（Internet Watch:インプレス）。
2008年10月29日 Google, Microsoft が OpenID 2.0 対応を発表[1]。
2014年2月26日、OpenID Connectによって置換えられた。
(引用:https://ja.wikipedia.org/wiki/OpenID_Authentication_2.0)

OpenID2.0とOpenID Connectの違い

まず、OpenID ConnectはOpenIDと名前がついていますが、プロトコルとしてはOAuth2.0の流れを汲んだものです。
OpenID Connectが登場する前はOpenID2.0とOauth2.0が存在していました。
OAuth2.0の連携の仕組みはTwitterやFacebookなどの巨大SNSに広く親しまれていましたが、OpenID 2.0では、ID情報の連携はできるもののAPI連携には利用できないなど、課題が存在していました。
そのような状況を打開するべく、
OAuth 2.0をベースにOpenIDを設計し直したものが、OpenID Connectです。
じゃー全部OAuth2.0でいいじゃんという感じですが、
OAuthは認可(権利を与える)、OpenIDは認証(誰であるか確認する)という役割の違いがあります。

参考
https://www.openid.or.jp/document/