Session Tokens - Temporary Authentication Credentials

About 2 min read

セッショントークンとは、ユーザーのログイン状態を維持するためにサーバーまたはクライアントが 発行する一時的な識別子です。 HTTP は本質的にステートレスなプロトコルであり、 リクエストごとに接続が独立しています。セッショントークンはこのステートレス性を補い、 「このリクエストは先ほどログインしたユーザー A からのものだ」とサーバーが判断するための 仕組みです。 Web アプリケーションのセキュリティにおいて、認証と並ぶ最重要の要素といえます。

HTTP のステートレス性とセッション管理

HTTP/1.0 の時代、 Web は文書を取得するためのシンプルなプロトコルでした。 リクエストとレスポンスが 1 対 1 で完結し、前後の文脈を持たない設計です。 しかし、 EC サイトのショッピングカートやログイン機能が求められるようになると、 「状態の保持」が不可欠になりました。 1994 年に Netscape の Lou Montulli が Cookie を発明し、ブラウザにサーバー発行の識別子を保存させる仕組みが生まれました。 これがセッション管理の原点です。

現在のセッション管理は、サーバーサイドセッションとトークンベースセッションの 2 つのアプローチに大別されます。どちらを選ぶかは、アプリケーションのアーキテクチャと セキュリティ要件によって決まります。

Cookie ベース vs トークンベース (JWT)

サーバーサイドセッションでは、サーバーがセッション ID を生成し、対応するセッションデータを サーバー側 (メモリ、データベース、 Redis など) に保存します。クライアントには セッション ID のみを Cookie で渡し、以降のリクエストでこの ID を送信させます。 サーバーが状態を管理するため、セッションの無効化 (ログアウト、強制切断) が即座に行えます。

一方、 JWT (JSON Web Token) に代表されるトークンベースの方式では、ユーザー情報と 有効期限を含むトークン自体に状態を埋め込みます。サーバーはトークンの署名を検証するだけで 認証が完了するため、セッションストアが不要でスケーラビリティに優れます。 しかし、一度発行した JWT を即座に無効化することが困難という根本的な課題があります。 ユーザーがパスワードを変更しても、既存の JWT は有効期限まで使い続けられてしまうのです。 この問題を緩和するために、短い有効期限 (15 分程度) のアクセストークンと、 長い有効期限のリフレッシュトークンを組み合わせるパターンが一般的です。

セッションに対する攻撃

セッショントークンは攻撃者にとって格好の標的です。セッションハイジャックは、 有効なセッショントークンを窃取してユーザーになりすます攻撃です。XSS 脆弱性を悪用して JavaScript から Cookie を読み取る手法が代表的です。

セッション固定攻撃 (Session Fixation) は、攻撃者が事前に用意したセッション ID を 被害者に使わせる手法です。被害者がそのセッション ID でログインすると、攻撃者は 同じセッション ID で認証済みの状態にアクセスできます。対策として、ログイン成功時に セッション ID を再生成する (セッションの再発行) ことが必須です。CSRF 攻撃も セッショントークンの存在を前提とした攻撃であり、セッション管理と密接に関連しています。セッションハイジャック対策やセッショントークン窃取の防御策で 具体的な対策を確認できます。

Cookie 属性によるセキュリティ強化

セッショントークンを Cookie で管理する場合、適切な属性設定がセキュリティの要です。Secure 属性は HTTPS 接続時のみ Cookie を送信するよう制限し、通信経路の暗号化と 組み合わせて盗聴を防ぎます。 HttpOnly 属性は JavaScript からの Cookie アクセスを禁止し、 XSS によるトークン窃取を防止します。SameSite 属性はクロスサイトリクエスト時の Cookie 送信を制御し、 CSRF 攻撃のリスクを軽減します。

これら 3 つの属性は「セッション Cookie の三種の神器」とも呼ばれ、 いずれか 1 つでも欠けるとセキュリティホールになり得ます。Web security books on Amazonでも、 Cookie 属性の設定は最初に解説される基本事項です。

トークンの有効期限設計

有効期限の設計は、セキュリティと利便性のトレードオフそのものです。 短すぎればユーザーは頻繁に再ログインを強いられ、長すぎればトークン漏洩時の被害が拡大します。 一般的な指針として、銀行などの高セキュリティサービスでは 15-30 分、 一般的な Web サービスでは 1-24 時間、 SNS のような利便性重視のサービスでは 数週間から数ヶ月が設定されます。ブラウザのパスワード安全性も セッション管理と関連する重要なトピックです。