🦁

【図解で解説】セッション ベースの認証について

2024/12/26に公開

セッション ベースの認証とは

セッションIDを使ってWebサービスの利用者が誰であるかを確認するプロセスのことです。
ではこの認証の流れについて詳しく解説していきます。

認証の流れ

① クライアント側でメールアドレスとパスワードを入力しログインを実行します。この処理がサーバーに送信されます。

② 入力されたメールアドレスとパスワードでどの利用者か確認できた場合、セッションを作成します。
そのセッションデータはデータベースまたはRedisなどのメモリ内キャッシュに保存します。
このデータにはユーザーID、セッションの有効期限、その他のメタデータが含まれる場合があります。

③ サーバーはCookieの形式で、セッションIDをクライアントに返します。

④ クライアント側で後続のリクエストを実行する際に、リクエストごとにセッションID Cookieを自動的に送信します。

④ サーバーはセッションIDを取得し、セッションが保存されたところの中に該当のセッションがないか確認します。
もしセッションIDが存在すれば、クライアントがログイン済みのユーザーであるか確認できたので、問題なくレスポンスを返すようにします。

引用:What Is JWT and Why Should You Use JWT

セッションとは

セッションとは通信の開始から終了までを指します。

通信の開始クライアント側がセッションIDを保持した時になります。
クライアント側でセッションIDを保持しているので、サーバー側との通信ができるようになるからです。

次に通信の終了について解説します。

① まず、クライアント側でサーバー側にログアウトを要求します。
そのリクエストにはセッションIDを渡しておきます。

② 次に、サーバーはセッション情報を削除します。

③ 最後に、サーバーがクライアントにログアウト成功した旨のレスポンスを返します。
その後に、クライアント側で保持しておいたセッション情報を削除します。

クライアント側でセッション情報がない状態になるので、通信は終了状態になります。

引用:セッション管理の仕組み

Cookieとは

CookieWEBサーバーとWEBブラウザ間で状態を管理する仕組みのことです。

① WEBサーバーがセッションIDをCookieとしてクライアントに渡します。
Cookieの情報はWEBブラウザに保管されます。

② クライアントがWEBサーバーにリクエストを送信する際に、Cookieの情報を一緒に送信します。

③ WEBサーバーはCookieの情報をもとにクライアントを識別することで、連続性のある動作を管理することができます。

引用:#62【サクッと学べる支援士対策】cookie

セッションベース認証のメリット

標準的な仕組み

HTTPプロトコルに統合されている
CookieはHTTPプロトコルの一部として設計されており、ほとんどのブラウザやサーバーでサポートされています。
古いシステムやブラウザでも動作するため、幅広い環境で利用可能です。

自動送信

クライアント側の自動化
一度Cookieをセットすると、ブラウザが以降のリクエストで自動的にCookieを送信します。
開発者がリクエストごとに認証情報を明示的に設定する必要がありません。

利便性の向上
ユーザー側でもログイン情報の入力を繰り返す必要がない。

シンプルな実装

開発コストが低い
Cookieの操作は基本的な機能であり、フレームワークやライブラリを使用せずとも容易に実装可能です。

学習コストが低い
Cookieの基本的な仕組みはシンプルで、開発者が学びやすいです。

セッションベース認証のデメリット

セキュリティリスク

セッションハイジャック
攻撃者がCookieを盗むことで、不正に認証済みユーザーとしてシステムにアクセスできます。

クロスサイトスクリプティング
不正なスクリプトが注入され、Cookie情報が盗まれるリスクがあります。

スケーラビリティ

セッション管理の負荷
サーバーがセッションを保持する必要があるため、ユーザー数が増加するとセッション管理に負荷がかかります。

分散システムでの問題
複数のサーバーで負荷分散している場合、セッション情報を共有するための仕組み(セッションストアやデータベース)が必要となり、複雑化します。

ストレージ制限
Cookieのサイズ制限は一般的に4KB程度です。
認証情報が増えたり、余計なデータを含めると、制限に達する可能性があります。

HTTP専用設定の不備

Secure属性が設定されていないと、HTTP通信を通じてCookieが漏洩する可能性があります。
HttpOnly属性が設定されていないと、JavaScript経由でCookieが取得されるリスクが高まります。

これらの理由から、最近ではCookieベースの認証に加えて、トークンベースの認証(JWT、OAuth 2.0)が好まれることがあります。

Discussion