More than 5 years have passed since last update.

OAuth認証をBasic認証と比較してみる

Last updated at 2018-01-12Posted at 2018-01-09

OAuth認証に仕組みがわからなかったので調べたことのまとめ。
Basic認証と何が違うのか、OAuth認証にはどんなメリットがあるのか書いてみた。
間違ってたらマサカリ大歓迎なのでよろしくお願いいたします。

OAuth認証とはなにか　

あるWebサービスに別の外部サービスを利用してリソースアクセスの権限を認可する仕組み
OAuth認証では、「認可を通して認証する」ということらしい。
- News Picksにログインするときにツイッターのアカウントを利用してログインするのはOAuth認証
- Webサービスが別の外部サービスに「そのサービスでユーザーが使っているこの情報の提供を許可してくれない？」と聞いて、ユーザーが許可したら、その別の外部サービスからデータをとる許可証をWebサービスに提供するって仕組み

認証と認可という言葉は違うみたいです。ここについてはまだ勉強不足なので、こちらの記事が詳しいです。

まず「認証」は英語では Authentication と言います。長いので略して AuthN と書いたりすることもあります。意味としては通信の相手が誰（何）であるかを確認することを表します。純粋な「認証」を考えるにあたっては「リソース」やそれに対する「権限」という概念は登場しません。

一方「認可」は英語では Authorization と言います。略して AuthZ（AuthRと書く場合もあるらしいです）です。意味としてはとある特定の条件に対して、リソースアクセスの権限を与えることを表します。純粋な「認可」には、「誰」という考え方はありません。
https://dev.classmethod.jp/security/authentication-and-authorization/

Basic認証とは

あるWebサービスに、ユーザーIDとパスワードを渡して認証する仕組み
実はbase64認証という、暗号化を行っているので、一応Webサービス上には暗号化された暗号化された状態には保持されるんだって
- HTTP heaederに Basic {base64で暗号化された文字}
ただ、その暗号化されたものは割と簡単に解読されてしまうんだってさ
- なので使う場合は、だいたいhttps通信で行うことが推奨されている

base64の暗号化は、Linux上で簡単に行うことができるので、実際にやってみるとこんな感じ。

echo "Basic $(echo -n 'admin:root' | base64 -w 0)"
Basic YWRtaW46cm9vdA==

ユーザーID：admin
パスワード：root
の場合で、base64の暗号化を行うと、Basic YWRtaW46cm9vdA==のような形で出てくる。

BASIC認証のヘッダである、Authorization: Basic {base64の文字} を作りたくなりました。Linuxだと改行が入ってしまうようなので、 echo に -n オプションを指定するとよい。
https://qiita.com/reoring/items/c73291229a2826d52132

base64ってなんだ

wikipediaによるとエンコーディングの方式らしい。つまり、ユーザーIDとパスワードを一気にエンコードすることで、認証を行えるようである。

Base64は、データを64種類の印字可能な英数字のみを用いて、それ以外の文字を扱うことの出来ない通信環境にてマルチバイト文字やバイナリデータを扱うためのエンコード方式である。
https://ja.wikipedia.org/wiki/Base64

base64は、簡単に解読できる

で、これは暗号化というよりももはやエンコードなので、うまく通信をとってくれば、簡単に解読できる。

$ echo "YWRtaW46cm9vdA==" > encoded.txt #encoded.txtにbase64エンコードされた文字列を挿入
$ cat encoded.txt
YWRtaW46cm9vdA==
$ base64 -d encoded.txt
admin:root

OAuthを使うメリット

エンドユーザーのメリット
- IDとパスワードをクライアントアプリに預けなくてもよいので、クライアントアプリに全権限を与えなくてもよい(セキュリティ)
- クライアントアプリに与える権限を事前に確認できる(セキュリティ)
- ユーザの登録の手間の減少
クライアントアプリ
- 複数のコンシューマが接続している場合、それらコンシューマのアクセス管理（ルールの変更、削除など）をサービスプロバイダ上で一元管理できる
- 自サービス上でユーザ情報を管理しなくても、ユーザ情報が利用できる(セキュリティ問題の回避)
- 嘘プロフィールの減少(例：TinderやPairsはFacebook Authのみを利用許可しているので、さくらが少ない)
- シェア等が増える可能性(例：Pengeeeはauthのおかげで利用が楽になった)

セキュリティの面と、利便性の面があるみたいですね。利便性の面は面白くて、例えば出会い系だとOAuth認証を使ったほうが良い点は、なりすましが減って質の高いアカウントのみが登録しやすいってところだと思います。特にPairs、TinderはFacebookのOAuthのみしか対応していないのですが、認証後も友達数をPairsは取得しているので、そこからユーザー数の質が担保されるということで、こういうところでもOAuthのメリットはあるみたいです。

ここ最近で言うと、拡散性という意味でもOAuth認証を使うメリットは大きいです。例えばPeingなんかもそうですが、ツイッターのOAuthを使っているので、シェアされやすい仕組みとなっております。

Basic認証と比べるとわかりやすいかも

Basic認証はユーザー名とパスワード入れてログインするあれ。それとOAuthを比較してみます。Basic認証だとセキュリティ的に危ないことが多いです。

ユーザー
- IDとパスワードをクライアントアプリに預ける必要があり、パスワード漏洩したら全権限でやられたい放題
  - OAuth認証なら特定の情報の利用だけ許可しているものの、basic認証だと全権限を与えてしまうので、勝手にアカウント消されたりするかも
- ユーザの登録の際にメールアドレスとパスワードを入力しなければいけないので面倒くさい
  - OAuth認証なら、ワンクリックで認証できる
クライアントアプリ
- パスワードが漏洩したら、セキュリティリスク的に大変
- Basic認証だとemailアドレスがあれば無限にアカウントを作れるので偽プロフィール作り放題（メールアドレスがあるだけ作り放題）で、サービスの質が落ちる
  - OAuth認証であれば、OAuth Provider（後述）がアカウントを一個しか持たせないことが多いので、さくらを作られることもない(例 Pairs Tinder)

OAuthの登場人物

クライアントアプリ, OAuth Consumer(Client) (例：Qiita)
- OAuthで情報を利用するアプリ(consume)だからOAuth Consumer
サービスプロバイダ, OAuth Service Provider, (例：Twitter)
- OAuthで情報を提供するからOAuth Provider
ユーザー, User

OAuthの仕組み

ユーザーの行動
- クライアントアプリでログインボタンをクリックする
- サービスプロバイダの認証ページにリダイレクトされる
- OKを押す
- 認証完了
OAuthの処理
- OAuth ClientはOAuth ServerにWebブラウザのリダイレクトを用いて認可要求を送る
- OAuth ServerはOAuth Clientがアクセスを求めているユーザーデータについてユーザーに説明し, アクセス許可を得る
- OAuth ServerはOAuth ClientにWebブラウザのリダイレクトを用いて認可コードを含む認可応答を返す
- OAuth Clientは受け取った認可コードを用いてOAuth ServerにHTTPリクエストを送り, アクセストークンを取得する

所感

現状わかったところだけまとめました。ほかのことがわかり次第、どんどん内容を追加していきます。

参考URL

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up