読む：一番分かりやすい OAuth の説明
Yug (やぐ)こちら読む
Yug (やぐ)リソースサーバーってそういうことなのか
ユーザーのデータを管理するサーバーがあります。これを『リソースサーバー』と呼びます。
DB APIとかWeb APIとかが含まれてそう
Yug (やぐ)あーリソースサーバの窓口がAPIか
じゃあAPIとイコールでは無さそう
DBサーバー / DB APIみたいなイメージかも
Yug (やぐ)なるほど
（１２）API を守る仕組みのベストプラクティスでは、あらかじめクライアントアプリケーションに『アクセストークン』というものを持たせておきます。アクセストークンは、当該クライアントアプリケーションがユーザーのデータを利用することを許可されていることを示すものです。
（１３）クライアントアプリケーションは、ユーザーのデータを要求する際、アクセストークンを提示します。
なら多分アクセストークンってJWTとかのことだな
Yug (やぐ)認可サーバー、なるほど
（１７）この仕組みを機能させるためには、あらかじめクライアントアプリケーションにアクセストークンを渡しておく必要があります。
（１８）必然の帰結として、アクセストークンを発行する係が必要となります。
（１９）アクセストークンを発行する係、
（２０）これを『認可サーバー』と呼びます。
これこそ以下で言うところのIDプロバイダ(Googleなど)が該当しそうだ
シングルサインオンを機能させるために中間で頑張ってくれてるやつ
Yug (やぐ)そうなのか
注：認可サーバーの役割とリソースサーバーの役割を一つのサーバーが兼ねることもよくあります。
Yug (やぐ)なんか認証求めてるところがすごくcookieみたいだ
（３１）ここまでは、認可サーバーがいきなりアクセストークンを生成してクライアントアプリケーションに発行するという流れでしたが、実際は、アクセストークンを発行する前にユーザーに確認を取ります。
（３２）まず、クライアントアプリケーションが認可サーバーに対してアクセストークンを要求します。
（３３）すると、認可サーバーは、クライアントアプリケーションが要求している権限を与えるかどうかをユーザーに確認します。
（３４）ユーザーがクライアントアプリケーションに権限を与えることを了承すれば、
（３５）認可サーバーはアクセストークンを生成し、
（３６）クライアントアプリケーションにアクセストークンを発行します。
Yug (やぐ)ほー、OAuth 2.0ってそういうものなのか
（３７）さて、今ここで黄色い楕円で囲った部分ですが、
（３８）これは、アクセストークンの要求とその応答を表しています。
（３９）そして、この部分を標準化したものが『OAuth 2.0』です。OAuth 2.0 の詳細は、技術文書 RFC 6749 で定義されています。
以下2つの部分を標準化した仕様みたいなものがOAuth 2.0
- クライアントアプリから認可サーバーへのアクセストークン要求方法
- 認可サーバーからクライアントアプリへのアクセストークン応答方法
裏側で行われるユーザーへの確認やアクセストークン生成という部分もOAuth 2.0の範囲に含まれるのかもしれない。"方法"と言っているので
Yug (やぐ)最後にリンクを載せていただいている記事を見ればもっと詳しくいろいろ学べそうだ