OAuthについて勉強してみました
sawa最近、仕事でIDaaSを使う機会があり、その際にOpenID ConnectやOAuthについて勉強が不足していると感じたので、調べてみようと思いました。
認証と認可
クラウドサービスの世の中では、認証と認可というキーワードは割と耳にする機会が多いと思います。
何をおいても「認証」というキーワードに目が行きがちで、「認可」というキーワードは最初は？でした。
言葉としてしっかり意味を分けて把握しておくべきだと学びました。
- 認証 ： その人が当人であることを確認すること
- 認可 ： アクセス権を与えること
言葉にすると全く違う意味というのが分かります。
普段はなんとなく「認証」に「認可」の意味を混同している場面も多いように感じます。
英語にしても違いがあります。
- 認証 ： Authentication
- 認可 ： Authorization
ちなみにOAuthは何の略なのかも調べました。
「Open Authorization」つまりOAuthは認可のことを指しています。
OAuth 1.0と2.0の違い
この記事では、OAuth2.0についての学習結果を書きますが、その過程で1.0と2.0の違いについてもみつけた記載があったので残しておきます。
- ブラウザ以外のアプリにも対応（スマホアプリなどでもOAuthが対応されたということです）
- 署名の生成が不要
- 短命のアクセストークンとリフレッシュトークンを利用
２ポチ目の理解ができていません。
署名の生成が不要ということで、TLSが必須で、アクセストークンの盗聴に強くなったという説明ですが、この意味は別途調べたいと思います。
OAuthが登場する前
Aさんが、アプリBを使用します。
アプリBはアプリCで管理されているAさんのコンテンツを利用する仕様です。
アプリCは、Aさんの認証が必要であり、アプリBからの要求に対してはAさんの認証情報（ID・パスワード）が必要になります。
これを解決するためには、Aさんの認証情報（ID・パスワード）をアプリBに持たせることが必要となります。
セキュリティリスク
アプリBにAさんの認証情報を持たせるということは、万が一アプリBから情報が漏洩すると、アプリCへの不正アクセスが可能となります。
普通に考えれば、認証情報をあちこちに渡してしまうと、その分だけ漏洩リスクが高まり、被害の確率を上げることになります。
OAuthの基本概念
同じ例に対して、OAuthの概念を簡単に説明してみます。
Aさんは、アプリCに対して、「アプリBからのアクセスを許可する」ことを伝えます。（この操作はAさんがアプリCの画面操作で行うことが一般的）
その結果として、アプリCはアプリBにアクセストークンを発行します。アクセストークンは、ワンタイムパスワードのようなものと捉えてください。
以降、アプリBがアプリCにリクエストする際には、このアクセストークンを渡すようにして、アプリCは渡されたアクセストークンの有効性を検証して問題なければ、アクセスを許可します。
以上のプロセスにより、AさんがアプリBにアプリCへのアクセス権を与えるという認可の行為となります。
OpenID Connectとの関係
OAuthは「認可」のプロトコルであり、「認証」のプロトコルではありません。
１点、疑問が残るのは、前述の「認可」のプロセスでは、AさんがアプリCに対しては「認証」を受けなければなりません。
ここについては、OAuthの範囲外ということになります。
一方で OpenID Connect は「認証」のプロトコルとされていますが、その原理にはOAuth2.0が使われているとのことです。
OpenID Connect については、次回記事にまとめてみます。
