はじめに

過去三年間、技術者ではない方々に OpenID Connect（オープンアイディー・コネクト）の説明を繰り返してきました^※1。 その結果、OpenID Connect をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。

^{※1：Authlete 社の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達』）。}

^{2017 年 10 月 23 日：『OpenID Connect 全フロー解説』という記事も公開したので、そちらもご参照ください。}

説明手順

（１）「こんにちは！ 鈴木一朗です！」
👁 01.png

（２）「え！？ 本当ですか？ 証明してください。」
👁 02.png

（３）「はい！ これが私の名刺です！」
👁 03.png

（４）「それでは証明になりません。名刺は誰でも偽造できてしまうので。」
👁 04.png

（５）後日、鈴木一朗さんは新しい名刺を持参しました。「こんにちは！ 鈴木一朗です！ 会社の『署名』入りの名刺を持ってきました！」
👁 05.png

（６）「確認しますのでお待ちください。」
👁 06.png

（７）名刺を受け取った人は、名刺を発行した会社に問い合わせます。「株式会社●●さん。」
👁 07.png

（８）「はい。何かご用でしょうか？」
👁 08.png

（９）「御社が発行した名刺についている『署名』が本物かどうか確認したいので、『公開鍵』をください。
👁 09.png

（１０）「はい、どうぞ。」（公開鍵を渡します。）
👁 10.png

（１１）公開鍵を用いて名刺についている署名を検証します。その結果→→→「株式会社●●様が発行された名刺であることを確認できました。」
👁 11.png

^{公開鍵については、書籍『暗号技術入門』の説明が分かりやすいので、そちらを参照してください。}

（１２）ここで、『発行者の署名付き名刺』という概念が登場しました。
👁 12.png

（１３）この概念に相当するものを『ID トークン』と呼びます。
👁 13.png

^{ID トークンの技術詳細は『[前編] IDトークンが分かれば OpenID Connect が分かる』で解説しています。}

（１４）名刺にその発行者がいるように、ID トークンにもその発行者がいます。
👁 14.png

（１５）ID トークンの発行者のことを『OpenID プロバイダー』と呼びます。
👁 15.png

（１６）ID トークンを受け取る側をクライアントアプリケーションと呼ぶとしたとき、OpenID プロバイダーとクライアントアプリケーションの関係を簡単に説明します。
👁 16.png

（１７）OpenID プロバイダーが ID トークンを生成し、
👁 17.png

（１８）クライアントアプリケーションに対して、ID トークンを発行します。
👁 18.png

（１９）先の図では、OpenID プロバイダーがいきなり ID トークンを生成してクライアントアプリケーションに発行するという流れでしたが、実際は、ID トークンを発行する前に、発行してよいかどうかをユーザーに確認します。 発行する場合は、ユーザーが本人であることも確認します。つまり、ユーザーの『認証』をおこないます。
👁 19.png

（２０）まず、クライアントアプリケーションが OpenID プロバイダーに対して ID トークンを要求します。
👁 20.png

（２１）すると、OpenID プロバイダーは、クライアントアプリケーションに ID トークンを発行してよいかユーザーに尋ねます。 同時に、ID トークンを発行する場合は、ユーザーに本人確認情報の提示を求めます。 つまり、ユーザーの『認証』をおこないます。
👁 21.png

^{ユーザー認証方法の典型例はユーザー ID とパスワードの提示ですが、認証には他にも様々な方法があります。}

（２２）ユーザーが ID トークンを発行することを了承し、本人確認情報の提示も適切に行われれば、
👁 22.png

（２３）OpenID プロバイダーは ID トークンを生成し、
👁 23.png

（２４）クライアントアプリケーションに ID トークンを発行します。
👁 24.png

（２５）さて、今ここで黄色い楕円で囲った部分ですが、
👁 25.png

（２６）これは、ID トークンの要求とその応答を表しています。
👁 26.png

（２７）そして、この部分を標準化したものが『OpenID Connect』です。 OpenID Connect の詳細は、技術文書『OpenID Connect Core 1.0』で定義されています。
👁 27.png

（２８）ところで、OAuth 2.0 の図（『一番分かりやすい OAuth の話』参照）と OpenID Connect の図、似ていると思いませんか？
👁 28.png

（２９）それもそのはずで、双方の処理フローが似ているのは、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 である」と説明したりしています。
👁 29.png

（３０）OAuth 2.0 と OpenID Connect のこのような関係から、何が起きるかといいますと、「OpenID プロバイダーが認可サーバーを兼ねる」ことが多くなります。
👁 30.png

（３１）ということは、クライアントアプリケーションは、ID トークンとアクセストークンの発行を両方同時に要求することも可能です。
👁 31.png

（３２）クライアントアプリケーションからのリクエストを受けると、OpenID プロバイダー兼認可サーバーは、クライアントアプリケーションに ID トークンとアクセストークンを発行してもよいか、ユーザーに尋ねます。 また、発行する場合には、ユーザーに本人確認情報の提示も求めます。
👁 32.png

（３３）ユーザーが ID トークンとアクセストークンの発行を了承し、本人確認情報の提示も適切に行われれば、
👁 33.png

（３４）OpenID プロバイダー兼認可サーバーは、ID トークンとアクセストークンを生成し、
👁 34.png

（３５）クライアントアプリケーションに対して ID トークンとアクセストークンを発行します。
👁 35.png

（３６）さて、最後になりますが、そもそも 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 入門編』解説動画を公開しました！