一番分かりやすい OAuth の説明

# **はじめに**

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

<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/)』）。Authlete アカウント登録は[こちら](https://so.authlete.com/accounts/signup)！</sup>

<sup>※2：そして２回目の資金調達！→『[AUTHLETE　凸版・NTTドコモベンチャーズ・MTIからプレシリーズA資金調達](https://prtimes.jp/main/html/rd/p/000000006.000024448.html)』(2018 年 2 月 15 日発表)</sup>

# **説明手順**

（１）ユーザーのデータがあります。
![01.png](https://qiita-image-store.s3.amazonaws.com/0/106044/faddc517-f937-9b9e-ef5c-4cf0f9b600c9.png)
<br/>

（２）ユーザーのデータを管理するサーバーがあります。これを『**リソースサーバー**』と呼びます。
![02.png](https://qiita-image-store.s3.amazonaws.com/0/106044/4fdcde94-d49e-a82b-eedf-a98ab7ead8ee.png)
<br/>

（３）ユーザーのデータを利用したい『**クライアントアプリケーション**』があります。
![03.png](https://qiita-image-store.s3.amazonaws.com/0/106044/2ce88d04-e559-25db-fecd-1848ec74c48b.png)
<br/>

（４）ユーザーのデータをやりとりする口を用意します。これを『**API（エーピーアイ）**』と呼びます。
![04.png](https://qiita-image-store.s3.amazonaws.com/0/106044/2b521256-8254-186e-6acc-ab18a9baa975.png)
<br/>

（５）クライアントアプリケーションがユーザーのデータをリソースサーバーに要求します。
![05.png](https://qiita-image-store.s3.amazonaws.com/0/106044/57a8d269-7569-c689-f974-8423f55363db.png)
<br/>

（６）リソースサーバーはクライアントアプリケーションにユーザーのデータを渡します。
![06.png](https://qiita-image-store.s3.amazonaws.com/0/106044/d44d3826-a261-407f-6c38-170ad5c27999.png)
<br/>

<hr/>

（７）もし、悪意のあるアプリがいたらどうなるでしょうか？
![07.png](https://qiita-image-store.s3.amazonaws.com/0/106044/91861c08-94aa-900c-954a-c3ee0a207547.png)
<br/>

（８）ユーザーのデータを要求しているのが悪意のあるアプリだとしても、
![08.png](https://qiita-image-store.s3.amazonaws.com/0/106044/a443d931-fc2f-8a40-de1f-cad403eff8d7.png)
<br/>

（９）リソースサーバーはユーザーのデータを渡してしまいます。
![09.png](https://qiita-image-store.s3.amazonaws.com/0/106044/a6af3145-8581-4723-a2df-3a1c903624d4.png)
<br/>

（１０）このままでは、悪意のあるアプリにもユーザーのデータが渡ってしまいます。
![10.png](https://qiita-image-store.s3.amazonaws.com/0/106044/d2a858df-d2c3-8870-9305-149e8e91254f.png)
<br/>

（１１）何かしら、API を守る仕組みが必要です。
![11.png](https://qiita-image-store.s3.amazonaws.com/0/106044/a6479776-2e4b-91bf-4c7a-bc8f36e3aa27.png)
<br/>

<hr/>

（１２）API を守る仕組みのベストプラクティスでは、あらかじめクライアントアプリケーションに『**アクセストークン**』というものを持たせておきます。アクセストークンは、当該クライアントアプリケーションがユーザーのデータを利用することを許可されていることを示すものです。
![12.png](https://qiita-image-store.s3.amazonaws.com/0/106044/ab3e86ef-adba-8658-680f-5ffee135d684.png)
<br/>

（１３）クライアントアプリケーションは、ユーザーのデータを要求する際、アクセストークンを提示します。
![13.png](https://qiita-image-store.s3.amazonaws.com/0/106044/8c59428e-a7e4-fdd9-5941-e9fcf29d03dd.png)
<br/>

（１４）リソースサーバーは、リクエストに含まれているアクセストークンを取り出し、
![14.png](https://qiita-image-store.s3.amazonaws.com/0/106044/d8274c1c-1003-69ba-4c42-d4d941218eeb.png)
<br/>

（１５）ユーザーのデータを利用する権限があるかどうかを調べます。
![15.png](https://qiita-image-store.s3.amazonaws.com/0/106044/cc60d121-6714-a254-16de-632d6bbaaee0.png)
<br/>

（１６）必要な権限があることを確認したあとに、ユーザーのデータをクライアントアプリケーションに渡します。
![16.png](https://qiita-image-store.s3.amazonaws.com/0/106044/14160454-8466-1e6e-6815-1143a0329dda.png)
<br/>

（１７）この仕組みを機能させるためには、あらかじめクライアントアプリケーションにアクセストークンを渡しておく必要があります。
![17.png](https://qiita-image-store.s3.amazonaws.com/0/106044/73272531-53f9-0640-f828-2f88ee116070.png)
<br/>

（１８）必然の帰結として、アクセストークンを発行する係が必要となります。
![18.png](https://qiita-image-store.s3.amazonaws.com/0/106044/7734f8ec-3e4a-2147-36b0-6ac4694988b8.png)
<br/>

<hr/>

（１９）アクセストークンを発行する係、
![19.png](https://qiita-image-store.s3.amazonaws.com/0/106044/aa952a5e-009e-a002-f4bf-c41be7195170.png)
<br/>

（２０）これを『**認可サーバー**』と呼びます。
![20.png](https://qiita-image-store.s3.amazonaws.com/0/106044/08199080-14e8-a659-7e4c-c564ebcc18dd.png)
<br/>

（２１）認可サーバーとクライアントアプリケーションの関係を簡単に説明します。
![21.png](https://qiita-image-store.s3.amazonaws.com/0/106044/8ce9442c-0d89-1848-03e4-4f4234472a7a.png)
<br/>

（２２）認可サーバーがアクセストークンを生成し、
![22.png](https://qiita-image-store.s3.amazonaws.com/0/106044/4bcb06f3-00c2-68da-4ca6-f74362818caf.png)
<br/>

（２３）クライアントアプリケーションに対してアクセストークンを発行します。
![23.png](https://qiita-image-store.s3.amazonaws.com/0/106044/8bc3d571-6117-3b2a-ea96-3af09915f8ca.png)
<br/>

<hr/>

（２４）ここまでの内容を復習します。登場人物は、認可サーバー、クライアントアプリケーション、リソースサーバーです。
![24.png](https://qiita-image-store.s3.amazonaws.com/0/106044/52003418-a462-3cf5-33d1-c080c6842a60.png)
<sub>注：認可サーバーの役割とリソースサーバーの役割を一つのサーバーが兼ねることもよくあります。</sub>
<br/>

（２５）認可サーバーがアクセストークンを生成し、
![25.png](https://qiita-image-store.s3.amazonaws.com/0/106044/60916eb2-b3df-5a5c-a0b9-f0d4295e9102.png)
<br/>

（２６）クライアントアプリケーションに対して発行します。
![26.png](https://qiita-image-store.s3.amazonaws.com/0/106044/24eea3ae-69af-73b1-f870-98be72737f62.png)
<br/>

（２７）クライアントアプリケーションは、アクセストークンを添えて、リソースサーバーにユーザーのデータを要求します。
![27.png](https://qiita-image-store.s3.amazonaws.com/0/106044/cf784296-67e4-adb9-bf1a-401e8487f14e.png)
<br/>

（２８）リソースサーバーはリクエストからアクセストークンを取り出し、
![28.png](https://qiita-image-store.s3.amazonaws.com/0/106044/2e933dc4-f7eb-b136-76d5-28e092cf03c7.png)
<br/>

（２９）アクセストークンがユーザーのデータを利用する権限を持っていることを確認し、
![29.png](https://qiita-image-store.s3.amazonaws.com/0/106044/85c03a06-6b5b-5626-30b5-5e8b77e7a767.png)
<br/>

（３０）ユーザーのデータをクライアントアプリケーションに渡します。
![30.png](https://qiita-image-store.s3.amazonaws.com/0/106044/319dd4e8-72b7-1af2-8bed-645120196b47.png)
<br/>

<hr/>

（３１）ここまでは、認可サーバーがいきなりアクセストークンを生成してクライアントアプリケーションに発行するという流れでしたが、実際は、アクセストークンを発行する前にユーザーに確認を取ります。
![31.png](https://qiita-image-store.s3.amazonaws.com/0/106044/35b74fc8-1615-25f6-a460-0ef60ea935b5.png)
<br/>

（３２）まず、クライアントアプリケーションが認可サーバーに対してアクセストークンを要求します。
![32.png](https://qiita-image-store.s3.amazonaws.com/0/106044/fee07313-d06a-e282-6c2e-624e0f8d9d63.png)
<br/>

（３３）すると、認可サーバーは、クライアントアプリケーションが要求している権限を与えるかどうかをユーザーに確認します。
![33.png](https://qiita-image-store.s3.amazonaws.com/0/106044/60f54d82-ca2d-aa13-50b4-ad992facf630.png)
<br/>

（３４）ユーザーがクライアントアプリケーションに権限を与えることを了承すれば、
![34.png](https://qiita-image-store.s3.amazonaws.com/0/106044/e99e7c48-7ddb-0f68-617c-06b7ca0e5e2e.png)
<br/>

（３５）認可サーバーはアクセストークンを生成し、
![35.png](https://qiita-image-store.s3.amazonaws.com/0/106044/4263a805-38f1-2e17-070b-fe6c31e265cf.png)
<br/>

（３６）クライアントアプリケーションにアクセストークンを発行します。
![36.png](https://qiita-image-store.s3.amazonaws.com/0/106044/bf8c55d3-3b21-5524-a293-988425d93813.png)
<br/>

（３７）さて、今ここで黄色い楕円で囲った部分ですが、
![37.png](https://qiita-image-store.s3.amazonaws.com/0/106044/595b0216-4eba-650b-f50d-b0028ba63617.png)
<br/>

（３８）これは、アクセストークンの要求とその応答を表しています。
![38.png](https://qiita-image-store.s3.amazonaws.com/0/106044/84d53069-9923-cb4b-dd33-426b1c1fa4e0.png)
<br/>

（３９）そして、この部分を標準化したものが『**OAuth 2.0**』です。OAuth 2.0 の詳細は、技術文書 **[RFC 6749](https://tools.ietf.org/html/rfc6749)** で定義されています。
![39.png](https://qiita-image-store.s3.amazonaws.com/0/106044/f8dc0cca-15c1-569d-c6e4-2055ea8c97cb.png)
<br/>

説明は以上です。


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

「アクセストークンの要求方法とそれに対する応答方法を標準化したものが OAuth 2.0 である」との説明が終わったあとは、クライアントアプリケーションが要求している権限を与えるかどうかをユーザーに確認する画面（**認可画面**）の説明（参考：『[認証と認可](http://qiita.com/TakahikoKawasaki/items/f2a0d25a4f05790b3baa#%E8%AA%8D%E8%A8%BC%E3%81%A8%E8%AA%8D%E5%8F%AF)』）、[RFC 6749](https://tools.ietf.org/html/rfc6749) で定義されている 4 つの認可フローの説明（参考：『[OAuth 2.0 全フローの図解と動画](http://qiita.com/TakahikoKawasaki/items/200951e5b5929f840a1f)』）をしていくことになります。

あと、『[一番分かりやすい OpenID Connect の説明](http://qiita.com/TakahikoKawasaki/items/498ca08bbfcc341691fe)』という記事も公開したので、是非ご覧ください。


# **おわりに**

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

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

**追記（2021-11-24）**
『**[Software Design 2021 年 10 月号](https://gihyo.jp/magazine/SD/archive/2021/202110)**』（2021 年 9 月 18 日発売）の第 2 特集『**挫折しない OAuth/OpenID Connect 入門**』を執筆させていただきました。