はじめに

過去三年間、技術者ではない方々に OAuth（オーオース）の説明を繰り返してきました^※1,※2。その結果、OAuth をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します。

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

^{※2：そして２回目の資金調達！→『AUTHLETE　凸版・NTTドコモベンチャーズ・MTIからプレシリーズA資金調達』(2018 年 2 月 15 日発表)}

説明手順

（１）ユーザーのデータがあります。
👁 01.png

（２）ユーザーのデータを管理するサーバーがあります。これを『リソースサーバー』と呼びます。
👁 02.png

（３）ユーザーのデータを利用したい『クライアントアプリケーション』があります。
👁 03.png

（４）ユーザーのデータをやりとりする口を用意します。これを『API（エーピーアイ）』と呼びます。
👁 04.png

（５）クライアントアプリケーションがユーザーのデータをリソースサーバーに要求します。
👁 05.png

（６）リソースサーバーはクライアントアプリケーションにユーザーのデータを渡します。
👁 06.png

---

（７）もし、悪意のあるアプリがいたらどうなるでしょうか？
👁 07.png

（８）ユーザーのデータを要求しているのが悪意のあるアプリだとしても、
👁 08.png

（９）リソースサーバーはユーザーのデータを渡してしまいます。
👁 09.png

（１０）このままでは、悪意のあるアプリにもユーザーのデータが渡ってしまいます。
👁 10.png

（１１）何かしら、API を守る仕組みが必要です。
👁 11.png

---

（１２）API を守る仕組みのベストプラクティスでは、あらかじめクライアントアプリケーションに『アクセストークン』というものを持たせておきます。アクセストークンは、当該クライアントアプリケーションがユーザーのデータを利用することを許可されていることを示すものです。
👁 12.png

（１３）クライアントアプリケーションは、ユーザーのデータを要求する際、アクセストークンを提示します。
👁 13.png

（１４）リソースサーバーは、リクエストに含まれているアクセストークンを取り出し、
👁 14.png

（１５）ユーザーのデータを利用する権限があるかどうかを調べます。
👁 15.png

（１６）必要な権限があることを確認したあとに、ユーザーのデータをクライアントアプリケーションに渡します。
👁 16.png

（１７）この仕組みを機能させるためには、あらかじめクライアントアプリケーションにアクセストークンを渡しておく必要があります。
👁 17.png

（１８）必然の帰結として、アクセストークンを発行する係が必要となります。
👁 18.png

---

（１９）アクセストークンを発行する係、
👁 19.png

（２０）これを『認可サーバー』と呼びます。
👁 20.png

（２１）認可サーバーとクライアントアプリケーションの関係を簡単に説明します。
👁 21.png

（２２）認可サーバーがアクセストークンを生成し、
👁 22.png

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

---

（２４）ここまでの内容を復習します。登場人物は、認可サーバー、クライアントアプリケーション、リソースサーバーです。
👁 24.png

_{注：認可サーバーの役割とリソースサーバーの役割を一つのサーバーが兼ねることもよくあります。}

（２５）認可サーバーがアクセストークンを生成し、
👁 25.png

（２６）クライアントアプリケーションに対して発行します。
👁 26.png

（２７）クライアントアプリケーションは、アクセストークンを添えて、リソースサーバーにユーザーのデータを要求します。
👁 27.png

（２８）リソースサーバーはリクエストからアクセストークンを取り出し、
👁 28.png

（２９）アクセストークンがユーザーのデータを利用する権限を持っていることを確認し、
👁 29.png

（３０）ユーザーのデータをクライアントアプリケーションに渡します。
👁 30.png

---

（３１）ここまでは、認可サーバーがいきなりアクセストークンを生成してクライアントアプリケーションに発行するという流れでしたが、実際は、アクセストークンを発行する前にユーザーに確認を取ります。
👁 31.png

（３２）まず、クライアントアプリケーションが認可サーバーに対してアクセストークンを要求します。
👁 32.png

（３３）すると、認可サーバーは、クライアントアプリケーションが要求している権限を与えるかどうかをユーザーに確認します。
👁 33.png

（３４）ユーザーがクライアントアプリケーションに権限を与えることを了承すれば、
👁 34.png

（３５）認可サーバーはアクセストークンを生成し、
👁 35.png

（３６）クライアントアプリケーションにアクセストークンを発行します。
👁 36.png

（３７）さて、今ここで黄色い楕円で囲った部分ですが、
👁 37.png

（３８）これは、アクセストークンの要求とその応答を表しています。
👁 38.png

（３９）そして、この部分を標準化したものが『OAuth 2.0』です。OAuth 2.0 の詳細は、技術文書 RFC 6749 で定義されています。
👁 39.png

説明は以上です。

このあとの説明手順

「アクセストークンの要求方法とそれに対する応答方法を標準化したものが OAuth 2.0 である」との説明が終わったあとは、クライアントアプリケーションが要求している権限を与えるかどうかをユーザーに確認する画面（認可画面）の説明（参考：『認証と認可』）、RFC 6749 で定義されている 4 つの認可フローの説明（参考：『OAuth 2.0 全フローの図解と動画』）をしていくことになります。

あと、『一番分かりやすい OpenID Connect の説明』という記事も公開したので、是非ご覧ください。

おわりに

API エコノミーの発展に伴い、API を守る技術である『OAuth 2.0』の概念を理解することは、技術者のみならず、ビジネスパーソンにとっても重要になってきました。本記事が、新たに OAuth 2.0 の概念を学ぶ必要のある方々の一助になれば幸いです。

追記（2020-03-20）
この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました！

追記（2021-11-24）
『Software Design 2021 年 10 月号』（2021 年 9 月 18 日発売）の第 2 特集『挫折しない OAuth/OpenID Connect 入門』を執筆させていただきました。