はじめに
過去三年間、技術者ではない方々に OpenID Connect（オープンアイディー・コネクト）の説明を繰り返してきました※1。 その結果、OpenID Connect をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。
※1：Authlete 社の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』）。
2017 年 10 月 23 日：『OpenID Connect 全フロー解説』という記事も公開したので、そちらもご参照ください。
説明手順
（１）「こんにちは！ 鈴木一朗です！」
（２）「え！？ 本当ですか？ 証明してください。」
（３）「はい！ これが私の名刺です！」
（４）「それでは証明になりません。名刺は誰でも偽造できてしまうので。」
（５）後日、鈴木一朗さんは新しい名刺を持参しました。「こんにちは！ 鈴木一朗です！ 会社の『署名』入りの名刺を持ってきました！」
（６）「確認しますのでお待ちください。」
（７）名刺を受け取った人は、名刺を発行した会社に問い合わせます。「株式会社●●さん。」
（８）「はい。何かご用でしょうか？」
（９）「御社が発行した名刺についている『署名』が本物かどうか確認したいので、『公開鍵』をください。
（１０）「はい、どうぞ。」（公開鍵を渡します。）
（１１）公開鍵を用いて名刺についている署名を検証します。その結果→→→「株式会社●●様が発行された名刺であることを確認できました。」
公開鍵については、書籍『暗号技術入門』の説明が分かりやすいので、そちらを参照してください。
（１２）ここで、『発行者の署名付き名刺』という概念が登場しました。
（１３）この概念に相当するものを『ID トークン』と呼びます。
ID トークンの技術詳細は『[前編] IDトークンが分かれば OpenID Connect が分かる』で解説しています。
（１４）名刺にその発行者がいるように、ID トークンにもその発行者がいます。
（１５）ID トークンの発行者のことを『OpenID プロバイダー』と呼びます。
（１６）ID トークンを受け取る側をクライアントアプリケーションと呼ぶとしたとき、OpenID プロバイダーとクライアントアプリケーションの関係を簡単に説明します。
（１７）OpenID プロバイダーが ID トークンを生成し、
（１８）クライアントアプリケーションに対して、ID トークンを発行します。
（１９）先の図では、OpenID プロバイダーがいきなり ID トークンを生成してクライアントアプリケーションに発行するという流れでしたが、実際は、ID トークンを発行する前に、発行してよいかどうかをユーザーに確認します。 発行する場合は、ユーザーが本人であることも確認します。つまり、ユーザーの『認証』をおこないます。
（２０）まず、クライアントアプリケーションが OpenID プロバイダーに対して ID トークンを要求します。
（２１）すると、OpenID プロバイダーは、クライアントアプリケーションに ID トークンを発行してよいかユーザーに尋ねます。 同時に、ID トークンを発行する場合は、ユーザーに本人確認情報の提示を求めます。 つまり、ユーザーの『認証』をおこないます。
ユーザー認証方法の典型例はユーザー ID とパスワードの提示ですが、認証には他にも様々な方法があります。
（２２）ユーザーが ID トークンを発行することを了承し、本人確認情報の提示も適切に行われれば、
（２３）OpenID プロバイダーは ID トークンを生成し、
（２４）クライアントアプリケーションに ID トークンを発行します。
（２５）さて、今ここで黄色い楕円で囲った部分ですが、
（２６）これは、ID トークンの要求とその応答を表しています。
（２７）そして、この部分を標準化したものが『OpenID Connect』です。 OpenID Connect の詳細は、技術文書『OpenID Connect Core 1.0』で定義されています。
（２８）ところで、OAuth 2.0 の図（『一番分かりやすい OAuth の話』参照）と OpenID Connect の図、似ていると思いませんか？
（２９）それもそのはずで、双方の処理フローが似ているのは、OpenID Connect が OAuth 2.0 の拡張仕様だからです。 OAuth 2.0 はアクセストークンを発行するための処理フローを定めていますが、それを流用し、ID トークンも発行できるようにしたのが OpenID Connect なのです。 これについて、OpenID Connect のウェブサイトでは、「OpenID Connect 1.0 は OAuth 2.0 プロトコル上のシンプルなアイデンティティーレイヤーである」と説明したり、「アイデンティティー・認証と OAuth 2.0 を足したものが OpenID Connect である」と説明したりしています。
（３０）OAuth 2.0 と OpenID Connect のこのような関係から、何が起きるかといいますと、「OpenID プロバイダーが認可サーバーを兼ねる」ことが多くなります。
（３１）ということは、クライアントアプリケーションは、ID トークンとアクセストークンの発行を両方同時に要求することも可能です。
（３２）クライアントアプリケーションからのリクエストを受けると、OpenID プロバイダー兼認可サーバーは、クライアントアプリケーションに ID トークンとアクセストークンを発行してもよいか、ユーザーに尋ねます。 また、発行する場合には、ユーザーに本人確認情報の提示も求めます。
（３３）ユーザーが ID トークンとアクセストークンの発行を了承し、本人確認情報の提示も適切に行われれば、
（３４）OpenID プロバイダー兼認可サーバーは、ID トークンとアクセストークンを生成し、
（３５）クライアントアプリケーションに対して ID トークンとアクセストークンを発行します。
（３６）さて、最後になりますが、そもそも ID トークンは何のためにあるのでしょうか？ それは、ユーザーが認証されたという事実とそのユーザーの属性情報を、捏造されていないことを確認可能な方法で、各所に引き回すためです。 一ヶ所で（＝一つの OpenID プロバイダーで）ユーザー認証をおこない、発行された ID トークンを引き回すことができれば、別の場所で何度もユーザー認証を繰り返す必要がなくなります。 短く言うと、『ID 連携』ができます。
説明は以上です。
このあとの説明手順
ID トークンの概念が理解できたので、技術的な話に進みましょう！
- IDトークンが分かれば OpenID Connect が分かる
- OpenID Connect 全フロー解説
- OAuth & OpenID Connect 関連仕様まとめ
- OAuth & OpenID Connect の不適切実装まとめ
- OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
おわりに
基本的には、OpenID プロバイダーになるつもりがなければ、OpenID Connect を実装する必要はありません。 しかし、OpenID Foundation の Financial-grade API ワーキンググループが策定した Financial-grade API 仕様では、条件によっては OpenID Connect のハイブリッドフローのサポートが必要となります（『世界最先端の API セキュリティー技術、実装者による『FAPI（Financial-grade API）』解説』参照）。 これは、より高いセキュリティーが求められる認可サーバーは、OpenID プロバイダーになるつもりがなくても OpenID Connect のサポートが求められるという意味です。 今後ますます OpenID Connect が重要になってきますね。
追記（2020-03-20）
この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました！