ログイン機能を支えるCookieとセッション【Day 1/30 2nd】
こんにちは、たわらです。
ログイン機能を実装するにあたって、Cookieとセッションの仕組みを整理します。
HTTPプロトコルはステートレス
Webアプリケーションでは、ブラウザからサーバーへHTTPリクエストを送り、受け取ったリクエストにしたがって、サーバーがブラウザへ必要な情報を返します。
基本的にWebアプリケーションを動かすとは、このHTTPリクエストとレスポンスのやり取りのことです。
で、このHTTPはステートレスなプロトコルです。ステートレスとは、状態を保持しません。つまり、以前の通信を記憶しておくことができないのです。
これで困るのは、ログインに成功しても、例えば自分の投稿記事を見たい、とHTTPリクエストを送っても、サーバー側はリクエストの送り主を判断することができないのです。
※HTTPは、すでにあったFTPというプロトコルとは異なる、通信手順が簡単なプロトコルが必要とされて新たに設計されたらしい。
Cookieの登場
で、このステートレスなHTTPプロトコルに状態を持たせるための技術がCookieです。
HTTPの仕様を拡張して、Webアプリケーションとブラウザの間で情報を交換することができるようになりました。
仕組みは、、、
WebサーバーからブラウザへHTTPのレスポンスの際に小さな情報を付け加えます。これがCookieという仕組みです。
Cookieを受け取ったブラウザは再度、同じサーバーへアクセスする際に、HTTPリクエストにそのCookieをくっつけます。
サーバーはリクエストにくっついたCookieの情報を見て、アクセスしたのが誰なのかを把握することができるのです。
ざっくり国民とマイナンバーの関係性に似ています。発行されたマイナンバーを役所で見せれば誰なのかを証明することができます。
Cookieの危険性とセッションの登場
ただ、Cookieにも問題があります。Cookieのセキュリティの問題です。
Cookieに保存したユーザー名とパスワードを盗まれたり、覗き見されたら大変です。
そこで、情報の安全性を高めるために、セッションと呼ばれる仕組みができました。
セッションはサーバー側に用意された仕組みのことで、アクセスして行う一連の行動のことを指します。
ピザの注文Webアプリケーションだと、「ログイン→ピザを選ぶ→注文内容の確認→ログアウト」という一連の流れがセッションと呼ばれます。
セッション機能を使えば、一つのブラウザから連続して送られてくる一連のリクエストの間で、「状態」を共有することができます。ページ遷移をしてもログイン状態を保つことができるのです。
そして、Cookieにセッションの状態を識別できるセッションIDを渡してあげるのです。
こうすることで、ブラウザとサーバーは単なる数字？ を交換するだけで、セッション状態を保持することができます。ログイン状態を保つことができる、というわけです。
まとめると
まとめるとログイン認証とは次のような流れになっているということです。
１ サーバー側でユーザー名、パスワードなどで、認証をチェック
２ サーバー側でセッションIDを発行して、セッション情報にログイン中のユーザー名を記録
３ セッションIDを格納したCookieをブラウザへ返す
４ ページ遷移などの際に、サーバー側へセッションIDを格納したCookieを返す
５ セッションIDからログイン中のユーザーを探す。
ちなみに、セッション情報のセキュリティを高めたい場合に、セッションの管理先をredisなどのKVS（キーバリューストア 保存項目がkeyとvalueのみのDB）に指定する方法を取る場合もある、そうです。
参考文献
プロになるためのWeb技術入門 pp96-120
読んでくださって、ありがとうございます。
たわら
この記事が気に入ったらサポートをしてみませんか？