📖

【認証?認可?】とにかくわかりやすいOAuth2.0

2024/07/30に公開

はじめに

みなさん、自社の開発するプロダクトのログイン方法って何使っていますか?
少し古いサービスだとほとんどがメールアドレスとパスワードでの認証を使っていると思われます。

そんな私が初めてこのZennを使おうとした時、衝撃が走りました。
なんと、ログイン方法がGoogleでのログインだけだったのです。

結構勇気のある決断だと思いましたが、よくよく考えてみると、ユーザーのログイン方法をGoogleログインに絞ることは、ユーザーの行動選択のハードルを取り払い、迷うことなくできるだけすぐに使えるようにする。
これはとても良い決断だと思いました。

自分の開発するプロダクトでも、ユーザーの選択肢をできるだけ絞ってあげて、Googleログインのみでアカウント認証ができるようにしたいと思ったので、こちらの記事にまとめながら共有をしたいと思います。

認証と認可

どのOAuth2.0の記事をみても、まずここから入ると思います。私も同じです。
まずは、この2つの言葉の使い分けをしっかりと理解することから始まると思っておりす。

認証

相手が何者であるかを確認するプロセスのこと
居酒屋に行った際に、年齢確認されることがあると思います。これは、認証のプロセスになります。

公安委員会から発行された運転免許証を提示して、運転免許証の顔写真と生年月日を見て、本人の顔を見て、確認すると思います。本人の顔とちょっと違うと、たまに和暦を聞かれたりもしますよね。

インターネットの世界でも同じように、本人を確認しようとする場合は少し難易度が上がります。
それは、誰でもなりすましできてしまうからです。

インターネットでは、以下の要素を使って認証を行います。

知識情報
メールアドレスとパスワード
秘密の質問の答え

所持(所有)情報
ICカード
トークン
セッション情報

生体情報
顔認証
指紋認証

認可

相手が何をする権限を持っているかを確認するプロセスのこと
認証が「この人が何者であるか」を確認するプロセスであるのに対し、認可は「この人が何をすることを許可されているか」を確認するプロセスです。

例えば、免許証を提示して認証をしたところで、その人が20歳になっていなければ、お酒を飲むことはできません。20歳以上でありお酒を飲むことが許可されているかどうかを確認するのが認可です。

インターネットの世界でも同じように、認証を通過したユーザーに対して、どのリソースにアクセスできるかを制御するために認可が行われます。

インターネットでは、以下の要素を使って認可を行います。

アクセスコントロールリスト(ACL)
リソースごとにアクセス権を設定するリスト。どのユーザーがどのリソースにアクセスできるかを明示的に定義します。

ロールベースアクセスコントロール(RBAC)
ユーザーに役割を割り当て、その役割に基づいてアクセス権を制御します。例えば、管理者、編集者、閲覧者といった役割ごとに異なるアクセス権を設定します。
属性ベースアクセスコントロール(ABAC)

ユーザーの属性(年齢、所属部署、役職など)や環境の属性(アクセスする時間帯、場所など)に基づいてアクセス権を制御します。

認可の場合、相手が何者であるかは関係ないのです。

一定の条件を満たしている場合、例えば「ハンターライセンスカード」を持ってさえいれば、ハンター専用サイトにアクセスする認可は得られるのです。

OAuth 2.0とは

OAuth 2.0 は、認可プロトコルであり、認証プロトコルではありません。

大事なことなのでもう一度言います。

OAuth 2.0 は、認可プロトコルであり、認証プロトコルではありません。

OAuth 2.0は、以下の登場人物たちが出てきます。

リソースオーナー(ユーザー)
データの持ち主。例:あなたとあなたのGoogleアカウント。

クライアント(アプリ)
あなたのデータを使いたいアプリ。例:予定管理アプリ。

認可サーバー
このクライアント(アプリ)にデータを使う許可を管理するサーバー。例:GoogleのOAuthサーバー。

リソースサーバー
データが保存されているサーバー。例:GoogleカレンダーのデータがあるGoogleのサーバー。

認可までの流れ

以下のような流れで、認可ができるようになっています。

なぜ認証と勘違いされるのか?

これは多分ですが、サービスのログインとかで使われるからではないでしょうか?

「Googleでログイン」などありますが、Googleでログインをしている際は、クライアントからリソースサーバーにアクセストークンを渡し、「認可」をしてもらい、メールアドレスというリソースにアクセスしているのです。

これは一見すると認証のフローですが、あくまでも認可をしてもらった結果を元に、クライアント側でメールアドレスの認証をしているのです。

Discussion