Help us understand the problem. What is going on with this article?

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

はじめに

過去三年間、技術者ではない方々に 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 の概念を学ぶ必要のある方々の一助になれば幸いです。

追記(2020-03-20)
この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました!

TakahikoKawasaki
株式会社 Authlete の共同創業者。プログラマー兼代表取締役社長。
https://www.authlete.com/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした