LoginSignup
1
0

More than 5 years have passed since last update.

@ot-nemoto

自分なりにOAuthについてまとめた

Posted at

OAuthの仕組みを説明できなかったので、OAuthを調べ理解したと思っている内容をまとめた。

OAuthとは？

権限の認可を行うための仕組み

「認証」と「認可」の違いは？

  • 認証 : 何かによって、対象の正当性を確認する行為
  • 認可 : 行政法学においては、行政行為のうち私人の契約、合同行為を補充して法律行為の効力要件とするものをいう（補充行為）

例えばGoogleにログインすれば、メールは見れたり、ドキュメントの閲覧・編集も可能ですし、カレンダー機能も使えます。
これはあなた自身がログインで証明(認証)された、と同時に、メールやその他の機能の利用権限も付与(認可)されています。
私は認証と認可が一緒になっていました。

OAuthの登場人物

RFC上、OAuthには4人の登場人物がいます。

  • client
  • resource owner
  • resource server
  • authorization server

一旦この登場人物は置いといて、ちょっとしたファイル受け渡しの例をあげます

OAuthの仕組みを使った書類の受け渡し

  • Bは書類を持っています。
  • CはBの書類を受け取りに来ました。
  • しかしBの持つ書類はCのものではなく、Aのものです。
  • もちろんこれは、他人の書類なので渡せません。

28315169957_9eaf3ef3e8_o.png

  • CはAの変わりに書類を受け取りに来ています。
  • といっても、本当にAの代わりに来たのかどうかわかりませんので、渡せません。

28315169907_394caa50e8_o.png

  • かといって、A本人が来てもBにはAが本人なのかの判断つきません。
  • これはBが書類を管理しているだけだからです。

28315169867_c47b1f6960_o.png

  • ではAはいつもどのようにしてBから書類を受け取っているのか？
  • Aが本人かどうかの確認が取れる受付担当のDがいます。
  • またDはBから書類受け取る許可も管理しています。
  • つまり、いつもはAは受付でDで自分であることを証明し、Dは書類を受け取る許可をAに与えることで、AはBから書類を受け取っています。
  • そこでCは、書類を受け取る許可をDにお願いした場合に、DがA本人と確認が取れてたらBから書類を受け取る許可を貰えるように依頼しておきます。

28315169797_6368f7d053_o.png

  • CはAからの依頼で書類を受け取りに来たので、Aと確認取ってほしい旨をDに伝えます。
  • DはAに連絡をとり、A本人であることを確認する。
  • A本人の確認が取れたので、受け取り許可をCに与えます。

28315169707_6c0aacc7a1_o.png

  • CはBに書類の受け渡しをお願いする。
  • このとき、Aからの委任状も一緒に渡す。
  • BはAからの委任状を確認できたので、CにAの書類を渡す。
  • BはめでたくAの書類を持って帰ることが出来ました。

43184428641_fe49b636a6_o.png

この場合の「認証」と「認可」は？

この話の流れで認可・認証は以下。

  • 認可：CはＡから書類を受け取り許可を受けている状態が認可
  • 認証：ＤがＡ本人からの依頼であることを確認しているが認証

AとD間の認証については、DがAを確認が出来るのであれば、電話だろうと、手紙だろうとなんでもよく、証明の方法については言及していません。CがAに代わって書類を受け取るための正当な認可をどう得るかの仕組みとなります。

また、正当な認可を得るために、重要な部分は以下になります。

  • AはCを信頼している
    • そもそもお願いをするのですから、お願いする相手は自分自身で見極める必要があります。
  • BはDを信頼している
    • その信頼関係があるので、Dが許可した認可にBは従います。
    • Dに悪意があれば場合、Bは誤った認可に対して書類を渡してしまうことになってしまいます。
  • DはAを証明することが出来る
    • 本当にAからの依頼かどうかが証明できなければ、Dは誤った相手に対して認可をしてしまうことになります。

28315169537_da410b2e69_o.png

見方を変えると、

  • Bは、Cが認可を受けていれば、Cの正当性までは問いません。
  • また、Aが誰であるかも証明する必要はありません。

つまり

  • Aの証明はDだけにすればよく、認証方法(実際だとパスワードとか)については、D以外に漏れることなく、認可だけをセキュアにCに付与することが出来ることになります。

最後に

書類の受け渡しの前に4人の登場人物について書きましたが、
書類の受け渡しの登場人物を、OAuthの登場人物と以下のようにマッピングできます。

28315169417_797114e3d0_o.png

例えば、これをGoogleカレンダーを操作するWebアプリに当てはめると、

  • client が Webアプリ
  • resource owner があなた
  • client はGoogleカレンダー( resource server ) を操作したいので、authorization server に認可依頼
  • authorization server は認可を許可していいかの判断を resource owner に対して問い合わせ、許可が出れば client に付与
  • client はGoogleカレンダー( resource server ) にアクセスして操作

という理解でいいかな？

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0