ログイン認証のいろいろ

こんにちは、なかにしです。

みなさん、認証は何を使用していますか？
ベーシック認証？ダイジェスト認証？

今回は、それらの認証方法と、その仕組みをちらっと紹介します。

それでは、いってみよう！

認証の歴史は長い…
認証方法ちらっとまとめ
まとめ

認証の歴史は長い…

古から、新しい認証方法が出てきては破られ、の繰り返しです。

破り方が確立し、危険だよとなったら IETF がRFCという形で発表してくれます。
（以下はハッシュ関数、MD5の例）
https://datatracker.ietf.org/doc/html/rfc6151

現代において情報は命と同等なので、
面倒ですが暗号についての知識はアップデートし続ける必要があります。

認証方法ちらっとまとめ

すべて紹介をしているとキリがないので、有名どころを紹介します。
※分かりやすく説明する為、簡略化している部分があります。ご了承下さい。

ベーシック認証

言わずもがな。一番シンプルで手軽な認証です。
ID、PWをbase64でエンコードして認証します。

可逆性があるので、盗聴されたら一発アウトです。
よって、 HTTPS通信での使用が推奨されています。

ダイジェスト認証

さすがにbase64だけじゃ危ないっしょ～ということで、暗号化を取り入れた認証です。
暗号化では、不可逆性のある「ハッシュ関数」を使用します。

Webサイトに訪問時に、サーバーからランダム文字列を受け取ります。
「サーバから受け取ったランダム文字列」と「クライアント側で生成したランダム文字列」と「PW」をハッシュ関数でハッシュ化し、それを「response」としてサーバに送ります。

サーバ側でもクライアント側と同様にハッシュ化して突合し、認証します。

セッションベース認証

ダイジェスト認証だと、ハッシュ化されてるとはいえ、
毎回PWを使用したresponseを生成して認証する必要があります。

それだとリスクあるよねってことで、
PWとは関係の無い「セッションID」を使用するやり方がセッションベース認証です。

まずユーザがログインし、サーバはログイン情報を検証。（①、②）
認証済ユーザであれば、サーバ側でセッションIDを発行し、保存します。（③）
保存場所は、メモリだったりDBだったりします。（メリデメを考慮して適切な場所に保存）

そして、サーバ側からクライアント側にセッションIDを返却し、
クライアント側はセッションIDをCookieに保存します。（④、⑤）

すると、次回以降はCookieに保存されたセッションIDのみで認証が可能になる、という仕組みです。

この認証方法では、初回ログイン時のID、PWと、
セッションIDが漏れるとオワリなので、HTTPS通信で使用することが推奨されます。

トークンベース認証

セッションベース認証はセッションを使用する為、ステートフルになります。
しかし、サーバ側でセッション情報の保存が必要な為、規模が大きくなるとその分サーバの負荷も増えます。

そこで、ステートレスにしてサーバの負荷を減らそうとしたのがトークンベース認証です。

まずユーザがログインし、サーバはログイン情報を検証。（①、②）
認証済ユーザであれば、サーバ側でトークン情報を発行し、返却します。（③、④）
※このとき発行・返却するのは、ユーザと紐付かないトークン情報です。
例えば、「トークン1（ページAとページBにアクセス出来る）」や「トークン2（ページCのみアクセス可能）」のようなものです。

クライアント側はトークン情報をCookieなどに保存します。（⑤）

すると、次回以降はCookieなどに保存されたトークン情報のみで認証が可能になる、という仕組みです。