Edited at

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

More than 1 year has passed since last update.


はじめに

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

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

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


説明手順

(1)ユーザーのデータがあります。

01.png


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

02.png


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

03.png


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

04.png


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

05.png


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

06.png



(7)もし、悪意のあるアプリがいたらどうなるでしょうか?

07.png


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

08.png


(9)リソースサーバーはユーザーのデータを渡してしまいます。

09.png


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

10.png


(11)何かしら、API を守る仕組みが必要です。

11.png



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

12.png


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

13.png


(14)リソースサーバーは、リクエストに含まれているアクセストークンを取り出し、

14.png


(15)ユーザーのデータを利用する権限があるかどうかを調べます。

15.png


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

16.png


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

17.png


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

18.png



(19)アクセストークンを発行する係、

19.png


(20)これを『認可サーバー』と呼びます。

20.png


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

21.png


(22)認可サーバーがアクセストークンを生成し、

22.png


(23)クライアントアプリケーションに対してアクセストークンを発行します。

23.png



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

24.png

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


(25)認可サーバーがアクセストークンを生成し、

25.png


(26)クライアントアプリケーションに対して発行します。

26.png


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

27.png


(28)リソースサーバーはリクエストからアクセストークンを取り出し、

28.png


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

29.png


(30)ユーザーのデータをクライアントアプリケーションに渡します。

30.png



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

31.png


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

32.png


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

33.png


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

34.png


(35)認可サーバーはアクセストークンを生成し、

35.png


(36)クライアントアプリケーションにアクセストークンを発行します。

36.png


(37)さて、今ここで黄色い楕円で囲った部分ですが、

37.png


(38)これは、アクセストークンの要求とその応答を表しています。

38.png


(39)そして、この部分を標準化したものが『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 の概念を学ぶ必要のある方々の一助になれば幸いです。