インターネットを通じたWEBサービス(例えば、Google, Amazon, Instagram等)を利用する際、「認証」をする機会がたくさんあります。
この記事では基礎的な認証の仕組みのBasic認証とフォーム認証(Cookieを使ったセッション管理の仕組み)についてまとめました。

そもそも認証って？

認証とは、サービスの利用者が確かに本人であることを確認することです。

Basic認証

HTTPで定義される認証方式の一つで、もっとも単純な実装方式です。
冒頭で挙げたような一般的なWEBサービスの認証として利用されることはほとんどありませんが、開発現場において本番リリース前のサイト/サービス等へのアクセスを特定の人だけに限定するための認証としてよく使われます。

Basic認証の仕組み

クライアントがBasic認証を必要とするページへのアクセスのリクエストをサーバへ送付する
401 Unauthorizedが返され、クライアントのブラウザ上にはID/PASSWORDの入力画面が表示される
入力されたID/PASSWORDを[ID]:[PASSWORD]の形でBase64エンコードしたSUTjgaDjgog6UGFzc3dvcmTjgaDjgog=がAuthorizationヘッダとしてHTTPリクエストメッセージ内に追加されクライアントからサーバへ再送信される
ID/PASSWORDが合っていた場合は、クライアントのブラウザにリクエストしたページが表示される

Basic認証はリクエストのたびに「はじめまして」状態

HTTPの特徴として「ステートレス」という性質があります。
一度認証したとしてもその認証状態を維持することができません。このため、ブラウザがリクエストメッセージにAuthorizationヘッダを自動的に付与し、リクエストのたびに認証を行ってページを表示しています。¹

フォーム認証(Cookieを使ったセッション管理)

Basic認証は、ステートレス(クライアントの状態を保持できない)ですが、WEBアプリケーションの目的によっては、ステートフル(状態を維持)にしておきたい場合(例：ECサイトのカートなど)があります。そんなときに便利なのがフォーム認証(Cookieを使ったセッション管理)です。
ここでのフォーム認証とは、HTMLフォームでID/PASSWORDを入力し、アプリケーション側で認証する方式を指します。

Cookieとは？

HTTPで状態を記憶するために使われる仕組みがCookieです。
サーバからクライアントのブラウザに対して送付されるデータ(Cookie)を使って、セッション管理の機能を実現しています。

Set-Cookie: <cookie-name>=<cookie-value>

Cookieを使用したセッション管理の仕組み

クライアントは、ログインページへアクセスするためにリクエストを送る
サーバは、クライアントに対してログインを要求する
クライアントはID/PASSWORDを入力してリクエストを送る
サーバは認証を行い、サーバ内にセッション情報(状態)を記録した上で、Cookie(セッションID)を発行²しクライアントブラウザに記録するよう指示する。

認証後は、セッション管理で状態維持

HTTPには状態を保持できないというステートレスという性質がありました。
しかし、CookieにセッションIDを持たせ、それをキーとしてサーバに記録したセッション情報(状態)を参照させることで、状態を保持することが可能となり、初回以降のアクセスでは認証は不要となります。³

まとめ

Basic認証・セッション管理どちらであっても、クライアント側で「ID/PASSWORD入力→ログイン」という操作を行う人間からするとほぼ同じことをしているように見えますが、その認証の仕組みは全く異なっています。

	Basic認証	セッション管理
状態の維持	できない	できる(サーバで保存)
ログイン	毎回実施	初回のみ実施
ブラウザで記録	ID/PASSWORD	セッションID

参考文献

Basic認証はブラウザを閉じると、再びアクセスする際に認証情報の入力を求められる。 ↩
Cookie自体にデータを保持させるのではなく、サーバに格納しているセッション情報にアクセスするためのキーとしてセッションIDをCookieとして付与している。Cookieは発行時に属性値を設定が可能で、例えばCookie値の有効期限などを設定することができる。 ↩
セッションの有効期限が設定さている場合は、期限が切れた時点で再ログインが必要。また設定されていない場合も、ブラウザを終了後は同様。 ↩