インターネットを通じた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ヘッダを自動的に付与し、リクエストのたびに認証を行ってページを表示しています。1
フォーム認証(Cookieを使ったセッション管理)
Basic認証は、ステートレス(クライアントの状態を保持できない)ですが、WEBアプリケーションの目的によっては、ステートフル(状態を維持)にしておきたい場合(例：ECサイトのカートなど)があります。そんなときに便利なのがフォーム認証(Cookieを使ったセッション管理)です。
ここでのフォーム認証とは、HTMLフォームでID/PASSWORDを入力し、アプリケーション側で認証する方式を指します。
Cookieとは？
HTTPで状態を記憶するために使われる仕組みがCookieです。
サーバからクライアントのブラウザに対して送付されるデータ(Cookie)を使って、セッション管理の機能を実現しています。
Set-Cookie: <cookie-name>=<cookie-value>
Cookieを使用したセッション管理の仕組み
- クライアントは、ログインページへアクセスするためにリクエストを送る
- サーバは、クライアントに対してログインを要求する
- クライアントはID/PASSWORDを入力してリクエストを送る
- サーバは認証を行い、サーバ内にセッション情報(状態)を記録した上で、Cookie(セッションID)を発行2しクライアントブラウザに記録するよう指示する。
認証後は、セッション管理で状態維持
HTTPには状態を保持できないというステートレスという性質がありました。
しかし、CookieにセッションIDを持たせ、それをキーとしてサーバに記録したセッション情報(状態)を参照させることで、状態を保持することが可能となり、初回以降のアクセスでは認証は不要となります。3
まとめ
Basic認証・セッション管理どちらであっても、クライアント側で「ID/PASSWORD入力→ログイン」という操作を行う人間からするとほぼ同じことをしているように見えますが、その認証の仕組みは全く異なっています。
| Basic認証 | セッション管理 | |
|---|---|---|
| 状態の維持 | できない | できる(サーバで保存) |
| ログイン | 毎回実施 | 初回のみ実施 |
| ブラウザで記録 | ID/PASSWORD | セッションID |
