セッションの仕組みとログインについて

セッションの仕組みの理解が浅くて気持ち悪くなってきたので、調べてみた。
以下、サーブレット標準に準拠のサーブレットコンテナ上でのアプリケーションに関して記載する。

セッション

HTTPはステートレスなプロトコルである
セッションは、HTTPでステートフル（1回のリクエストで完結しない場合に、前回のリクエストの情報（ログイン情報や買い物カゴなど）を保持）な処理を実現するための、期間をあらわす概念

セッションID

セッションを一意に識別するID
サーブレットコンテナが生成する。そのため、サーブレットコンテナの実装に依存する
セッションにおいて HttpServletRequest#getSession が初めて呼び出された際に HttpSession インスタンスが生成され、セッションIDはこのインスタンスのフィールドとして生成される
クライアントがセッションへの参加を選択した場合（クッキーを有効にしている、など）、サーブレットコンテナによってセッションIDがクライアントに渡される（そして、例えばクライアントのクッキーに保持される）
クッキーに設定されたセッションIDは、次回以降のリクエストの際にブラウザによってリクエストヘッダに設定される
ただし、セッションの有効範囲はそのWebアプリケーション(ServletContext)のみであり、別のコンテキスト内で直接参照することはできない

参考 Java API

ログイン状態保持機能の実現

ベーシック認証の場合で考えてみた。

前提

WEBアプリケーションサーバのベーシック認証機能を利用
認証対象URLにはトップ画面のみ指定する（※トップ画面以外へのアクセスは、サーバのメモリにセッションIDが有るかでログイン済みかを判定）

（※なお、認証を一度通過すれば、トップページ以下のディレクトリへのリクエストには必ず、Authorizationヘッダがブラウザによって付与される）

フロー

1. トップ画面へのリクエスト
2. 「401 Unauthorized」がレスポンスされる
3. ブラウザによってログインダイアログが表示される
4. ユーザが、IDとPWDを入力し、OKボタンを押下する
5. Authorizationヘッダが付与されたリクエストが送信される
6. WEBアプリケーションサーバが認証し、認証通過する
7. サーブレットでセッションIDを取得（WEBアプリケーションサーバがIDを新規作成）する
8. WEBアプリケーションサーバによって、レスポンスヘッダにセッションIDが設定される
9. クライアントのクッキーにセッションIDが登録される
10. 他の画面へのリクエスト時は、セッションIDのクッキーがリクエストヘッダに付与される
11. WEBアプリケーションサーバは、リクエストヘッダのセッションIDを、そのリクエストが所属するセッションのセッションIDと認識する
12. サーブレットでセッションIDを取得すると、上記セッションIDが渡される