はじめに

過去三年間、技術者ではない方々に 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 日発表)}

説明手順

（１）ユーザーのデータがあります。

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

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

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

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

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

---

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

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

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

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

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

---

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

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

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

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

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

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

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

---

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

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

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

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

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

---

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

説明は以上です。

このあとの説明手順

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

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

おわりに

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

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