【Webセキュリティ】ログイン認証の種類について

Webアプリのログインで使われる認証にも色々種類があるので分類しておきます。

Basic認証

Apache等のWebサーバーの設定で、該当のＨＴＭＬにアクセスする際にポップアップで認証を出すことが可能です。

Basic認証のデメリット

ユーザー名と、パスワードがプレインテキストで送信されるため、傍受されると成りすましされる可能性がある点。

Digest認証

これも、Basic認証と似ていて、Apache等のWebサーバーの機能であります。

Basic認証との違い

流れる情報をプレインテキストではなく、MD5で暗号化してから流すので、セキュリティ的に優れています。

フォーム認証（セッション認証、クッキー認証等とも呼ぶ。）

HTML上で、IDとパスワードを入力させる認証のことです。「パスワード」は、ハッシュ化しておいて、データベースに保存します。

パスワードのハッシュ化については、下記の記事でも解説していますので、参考にしてみて下さい。

【Webセキュリティ】ハッシュ関数(digest)、実装方法、パスワード運用について

Webアプリでは、これを使用した認証が非常に多いです。

ログイン認証の処理の流れ

ログインの状態は、サーバー側では、セッションとして保持します。

ブラウザ側ではクッキーにセッションIDを保持します。

ログイン以降のリクエストは、セッションIDを含めてクライアントはリクエストを行うことになります。

随時、サーバーはセッションIDのログイン状態をチェックして、セッションタイムアウトしていた場合はログイン画面にリダイレクトして、戻します。

なお、ユーザーがログアウトした場合は、サーバー側、クライアント側それぞれのセッションが破棄されます。

フォーム認証のメリット

利用者情報の保持にはセッションを活用するが、ユーザーがブラウザを起動してから、終了するまで誰がログインしているのかを簡単に確認することができる点。

フォーム認証のデメリット

Webサーバーが複数台に分かれている場合は、それぞれのサーバー間でクライアント状態の同期が必要になるため実装が難しくなる点です。

SSLクライアント認証

SSLクライアント証明書を用いる認証のことです。

トークン認証

モバイルアプリの多くは、フォーム認証ではなく、トークン認証で実装されています。

トークン認証では、フォーム認証のようにセッションで管理するのではなく、ログイン時に生成したトークンを使って認証を行います。

実装について

OAuthや、OAuth2等のフレームワークや、OpenID Connect等が使われたりします。

トークンには、色々あるようですが、JWT(Json Web Token)がその中でも有名だったりします。

詳しくは、下記の記事で解説しています。

JWT(Json Web Token)について(base64なども)

フォーム認証との違いやメリット

フォーム認証と異なり、システム側で状態を保持しないのでステートレスになります。

クライアントサイドでトークンを保持していた場合は、ユーザーはログイン状態となります。

なので、フォーム認証の比べて複数サーバーにスケールアウトしやすい認証方式といえます。

デメリット

トークンへの検証にDBを使用する場合は、DBアクセスがボトルネックになってしまうので、適度にキャッシュが必要になります。