一番分かりやすい OpenID Connect の説明

# **はじめに**

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

<sup>※1：[Authlete 社](https://www.authlete.com/)の創業者として資金調達のため投資家巡りをしていました（TechCrunch Japan：『[APIエコノミー立ち上がりのカギ、OAuth技術のAUTHLETEが500 Startups Japanらから1.4億円を調達](http://jp.techcrunch.com/2017/05/23/authlete-fundraise/)』）。</sup>

<sup>2017 年 10 月 23 日：『[OpenID Connect 全フロー解説](https://qiita.com/TakahikoKawasaki/items/4ee9b55db9f7ef352b47)』という記事も公開したので、そちらもご参照ください。</sup>


# **説明手順**

（１）「こんにちは！ 鈴木一朗です！」
![01.png](https://qiita-image-store.s3.amazonaws.com/0/106044/cb66fe98-b58e-2656-300c-9179952b4dcf.png)
<br/>

（２）「え！？ 本当ですか？ 証明してください。」
![02.png](https://qiita-image-store.s3.amazonaws.com/0/106044/91c7666b-c3f2-6973-96b5-86a73dff2bd2.png)
<br/>

（３）「はい！ これが私の名刺です！」
![03.png](https://qiita-image-store.s3.amazonaws.com/0/106044/24c3074c-7078-3ecd-b5e1-b6d8dbe8854e.png)
<br/>

（４）「それでは証明になりません。名刺は誰でも偽造できてしまうので。」
![04.png](https://qiita-image-store.s3.amazonaws.com/0/106044/32719fd6-1076-d6fc-251d-51a2a0921faf.png)
<br/>

（５）後日、鈴木一朗さんは新しい名刺を持参しました。「こんにちは！ 鈴木一朗です！ 会社の『**署名**』入りの名刺を持ってきました！」
![05.png](https://qiita-image-store.s3.amazonaws.com/0/106044/aff5d76a-5bc9-e0de-ab96-4f67c5a70b69.png)
<br/>

（６）「確認しますのでお待ちください。」
![06.png](https://qiita-image-store.s3.amazonaws.com/0/106044/e7eef512-8bef-40d6-f17a-438b0836db6e.png)
<br/>

（７）名刺を受け取った人は、名刺を発行した会社に問い合わせます。「株式会社●●さん。」
![07.png](https://qiita-image-store.s3.amazonaws.com/0/106044/6911c0c1-b49e-6140-fd5a-de85e80ab815.png)
<br/>

（８）「はい。何かご用でしょうか？」
![08.png](https://qiita-image-store.s3.amazonaws.com/0/106044/29b1300d-4b36-862a-5716-97b75f80afc5.png)
<br/>

（９）「御社が発行した名刺についている『**署名**』が本物かどうか確認したいので、『**公開鍵**』をください。
![09.png](https://qiita-image-store.s3.amazonaws.com/0/106044/da6a12d3-0988-f867-df3a-2b02702014a7.png)
<br/>

（１０）「はい、どうぞ。」（公開鍵を渡します。）
![10.png](https://qiita-image-store.s3.amazonaws.com/0/106044/f92bef30-7911-c651-956f-4ec8289e2140.png)
<br/>

（１１）公開鍵を用いて名刺についている署名を検証します。その結果→→→「株式会社●●様が発行された名刺であることを確認できました。」
![11.png](https://qiita-image-store.s3.amazonaws.com/0/106044/33774516-bfc6-b0d2-b6fa-db7ff5b44235.png)
<sup>公開鍵については、書籍『[暗号技術入門](https://www.amazon.co.jp/%E6%9A%97%E5%8F%B7%E6%8A%80%E8%A1%93%E5%85%A5%E9%96%80-%E7%AC%AC3%E7%89%88-%E7%B5%90%E5%9F%8E-%E6%B5%A9/dp/4797382228)』の説明が分かりやすいので、そちらを参照してください。</sup>
<br/>

（１２）ここで、『発行者の署名付き名刺』という概念が登場しました。
![12.png](https://qiita-image-store.s3.amazonaws.com/0/106044/7ae39e68-b0d1-0621-ff37-19ff4c6abfa1.png)
<br/>

（１３）この概念に相当するものを『**ID トークン**』と呼びます。
![13.png](https://qiita-image-store.s3.amazonaws.com/0/106044/ff5ee5ad-f0e6-f6f7-f2d0-f59e5cc4d6dc.png)
<sup>ID トークンの技術詳細は『[[前編] IDトークンが分かれば OpenID Connect が分かる](http://qiita.com/TakahikoKawasaki/items/8f0e422c7edd2d220e06)』で解説しています。</sup>
<br/>

（１４）名刺にその発行者がいるように、ID トークンにもその発行者がいます。
![14.png](https://qiita-image-store.s3.amazonaws.com/0/106044/70649887-22ba-0043-03bb-47ec592b2d17.png)
<br/>

（１５）ID トークンの発行者のことを『**OpenID プロバイダー**』と呼びます。
![15.png](https://qiita-image-store.s3.amazonaws.com/0/106044/b4c0b57d-ba88-2dd3-8d3a-54430bd3d9c7.png)
<br/>

（１６）ID トークンを受け取る側をクライアントアプリケーションと呼ぶとしたとき、OpenID プロバイダーとクライアントアプリケーションの関係を簡単に説明します。
![16.png](https://qiita-image-store.s3.amazonaws.com/0/106044/cc158d6b-7c1b-c908-9421-69f18ecf6bf8.png)
<br/>

（１７）OpenID プロバイダーが ID トークンを生成し、
![17.png](https://qiita-image-store.s3.amazonaws.com/0/106044/68e14a81-1049-8a6c-3cac-aab2f6d5ee9f.png)
<br/>

（１８）クライアントアプリケーションに対して、ID トークンを発行します。
![18.png](https://qiita-image-store.s3.amazonaws.com/0/106044/492135bc-af4c-76a5-7d27-07ccb0a5f2ad.png)
<br/>

（１９）先の図では、OpenID プロバイダーがいきなり ID トークンを生成してクライアントアプリケーションに発行するという流れでしたが、実際は、ID トークンを発行する前に、発行してよいかどうかをユーザーに確認します。 発行する場合は、ユーザーが本人であることも確認します。つまり、ユーザーの『**認証**』をおこないます。
![19.png](https://qiita-image-store.s3.amazonaws.com/0/106044/68f1157d-faca-52e9-560b-e114ef08c386.png)
<br/>

（２０）まず、クライアントアプリケーションが OpenID プロバイダーに対して ID トークンを要求します。
![20.png](https://qiita-image-store.s3.amazonaws.com/0/106044/f7e5af80-d190-7bf9-22e5-6912be0a2335.png)
<br/>

（２１）すると、OpenID プロバイダーは、クライアントアプリケーションに ID トークンを発行してよいかユーザーに尋ねます。 同時に、ID トークンを発行する場合は、ユーザーに本人確認情報の提示を求めます。 つまり、ユーザーの『**認証**』をおこないます。
![21.png](https://qiita-image-store.s3.amazonaws.com/0/106044/c016e2fc-d7e7-9b35-17ca-859d46f40613.png)
<sup>ユーザー認証方法の典型例はユーザー ID とパスワードの提示ですが、認証には他にも様々な方法があります。</sup>
<br/>

（２２）ユーザーが ID トークンを発行することを了承し、本人確認情報の提示も適切に行われれば、
![22.png](https://qiita-image-store.s3.amazonaws.com/0/106044/82173d7e-e6f7-604f-1802-1bb20f4f19d4.png)
<br/>

（２３）OpenID プロバイダーは ID トークンを生成し、
![23.png](https://qiita-image-store.s3.amazonaws.com/0/106044/c389018b-59ae-14ce-27fb-72a101b0cfd0.png)
<br/>

（２４）クライアントアプリケーションに ID トークンを発行します。
![24.png](https://qiita-image-store.s3.amazonaws.com/0/106044/be3c1d91-2302-5e47-e199-00d8ff27d021.png)
<br/>

（２５）さて、今ここで黄色い楕円で囲った部分ですが、
![25.png](https://qiita-image-store.s3.amazonaws.com/0/106044/850d4c6c-457a-b2ce-b42c-4d73f88ba89d.png)
<br/>

（２６）これは、ID トークンの要求とその応答を表しています。
![26.png](https://qiita-image-store.s3.amazonaws.com/0/106044/842ffe90-4d19-1d38-b0bc-576d3b626834.png)
<br/>

（２７）そして、この部分を標準化したものが『**OpenID Connect**』です。 OpenID Connect の詳細は、技術文書『**[OpenID Connect Core 1.0](http://openid.net/specs/openid-connect-core-1_0.html)**』で定義されています。
![27.png](https://qiita-image-store.s3.amazonaws.com/0/106044/7a166374-ee5f-e992-bc63-b860ee22b68b.png)
<br/>

（２８）ところで、OAuth 2.0 の図（『[一番分かりやすい OAuth の話](http://qiita.com/TakahikoKawasaki/items/e37caf50776e00e733be)』参照）と OpenID Connect の図、似ていると思いませんか？
![28.png](https://qiita-image-store.s3.amazonaws.com/0/106044/32c16f25-9872-0178-8e43-9f0502fe5d44.png)
<br/>

（２９）それもそのはずで、双方の処理フローが似ているのは、OpenID Connect が OAuth 2.0 の拡張仕様だからです。 **OAuth 2.0 はアクセストークンを発行するための処理フローを定めていますが、それを流用し、ID トークンも発行できるようにしたのが OpenID Connect なのです。** これについて、[OpenID Connect のウェブサイト](http://openid.net/connect/)では、「OpenID Connect 1.0 は OAuth 2.0 プロトコル上のシンプルなアイデンティティーレイヤーである」と説明したり、「アイデンティティー・認証と OAuth 2.0 を足したものが OpenID Connect である」と説明したりしています。
![29.png](https://qiita-image-store.s3.amazonaws.com/0/106044/3c6e32bb-9d6b-4995-74f8-2c2e4fd3ef27.png)
<br/>

（３０）OAuth 2.0 と OpenID Connect のこのような関係から、何が起きるかといいますと、「**OpenID プロバイダーが認可サーバーを兼ねる**」ことが多くなります。
![30.png](https://qiita-image-store.s3.amazonaws.com/0/106044/083b3dbe-5b6f-d753-61b9-790a5ebedf7d.png)
<br/>

（３１）ということは、クライアントアプリケーションは、ID トークンとアクセストークンの発行を両方同時に要求することも可能です。
![31.png](https://qiita-image-store.s3.amazonaws.com/0/106044/0032a62e-9089-5c72-33b8-56fff611d37b.png)
<br/>

（３２）クライアントアプリケーションからのリクエストを受けると、OpenID プロバイダー兼認可サーバーは、クライアントアプリケーションに ID トークンとアクセストークンを発行してもよいか、ユーザーに尋ねます。 また、発行する場合には、ユーザーに本人確認情報の提示も求めます。
![32.png](https://qiita-image-store.s3.amazonaws.com/0/106044/24dd5435-0bf4-a140-693a-a1efefb37847.png)
<br/>

（３３）ユーザーが ID トークンとアクセストークンの発行を了承し、本人確認情報の提示も適切に行われれば、
![33.png](https://qiita-image-store.s3.amazonaws.com/0/106044/f3161bbf-3901-d43c-8178-d7dbd640a178.png)
<br/>

（３４）OpenID プロバイダー兼認可サーバーは、ID トークンとアクセストークンを生成し、
![34.png](https://qiita-image-store.s3.amazonaws.com/0/106044/d899b16a-400d-8a2d-106a-b5db98b19485.png)
<br/>

（３５）クライアントアプリケーションに対して ID トークンとアクセストークンを発行します。
![35.png](https://qiita-image-store.s3.amazonaws.com/0/106044/7a12a53c-c7e5-2078-8c2f-eb4ea82304d7.png)
<br/>

（３６）さて、最後になりますが、そもそも ID トークンは何のためにあるのでしょうか？ それは、**ユーザーが認証されたという事実とそのユーザーの属性情報を、捏造されていないことを確認可能な方法で、各所に引き回す**ためです。 一ヶ所で（＝一つの OpenID プロバイダーで）ユーザー認証をおこない、発行された ID トークンを引き回すことができれば、別の場所で何度もユーザー認証を繰り返す必要がなくなります。 短く言うと、『**ID 連携**』ができます。

説明は以上です。


# **このあとの説明手順**

ID トークンの概念が理解できたので、技術的な話に進みましょう！

- [IDトークンが分かれば OpenID Connect が分かる](http://qiita.com/TakahikoKawasaki/items/8f0e422c7edd2d220e06)
- [OpenID Connect 全フロー解説](https://qiita.com/TakahikoKawasaki/items/4ee9b55db9f7ef352b47)
- [OAuth & OpenID Connect 関連仕様まとめ](http://qiita.com/TakahikoKawasaki/items/185d34814eb9f7ac7ef3)
- [OAuth & OpenID Connect の不適切実装まとめ](http://qiita.com/TakahikoKawasaki/items/efbbd2c5875577c911a3)
- [OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る](http://qiita.com/TakahikoKawasaki/items/f2a0d25a4f05790b3baa)


# **おわりに**

基本的には、OpenID プロバイダーになるつもりがなければ、OpenID Connect を実装する必要はありません。 しかし、[OpenID Foundation](http://openid.net/) の [Financial-grade API ワーキンググループ](http://openid.net/wg/fapi/)が策定した Financial-grade API 仕様では、条件によっては OpenID Connect のハイブリッドフローのサポートが必要となります（『[世界最先端の API セキュリティー技術、実装者による『FAPI（Financial-grade API）』解説](https://qiita.com/TakahikoKawasaki/items/83c47c9830097dba2744)』参照）。 これは、より高いセキュリティーが求められる認可サーバーは、OpenID プロバイダーになるつもりがなくても OpenID Connect のサポートが求められるという意味です。 今後ますます OpenID Connect が重要になってきますね。

**追記（2020-03-20）**
この記事の内容を含む、筆者本人による『**[OAuth & OIDC 入門編](https://www.youtube.com/watch?v=PKPj_MmLq5E)**』解説動画を公開しました！