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

  • 820
    いいね
  • 3
    コメント

はじめに

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

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

説明手順

(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 の概念を学ぶ必要のある方々の一助になれば幸いです。