はじめに
過去三年間、技術者ではない方々に 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 入門編』解説動画を公開しました！
追記（2021-11-24）
『Software Design 2021 年 10 月号』（2021 年 9 月 18 日発売）の第 2 特集『挫折しない OAuth/OpenID Connect 入門』を執筆させていただきました。