認証クッキーを使用した場合における Forms 認証のログインとログアウト動作で、サーバーとクライアントのやり取りがどのように行われているか調べてみましたので、備忘録として書いておきます。

ログアウト操作で、認証クッキーを削除するため、ポストバックして同じページにリダイレクトをかけていることと、ロール名クッキーの追加と削除が認証クッキーより 1 ステップ遅れるのが新しい発見でした。

認証クッキーを使用せず、代わりに URL に認証チケットを追加して送るケースではどうなっているかは別途調べる予定です。

***** ログイン *****

1. 匿名アクセスが許可されているあるページ（ここでは default.aspx とする）において、ログインしていない状態から LoginStatus をクリックする。
2. JavaScrip が起動してポストバック（default.aspx への POST 要求）がかかる。この時、サーバーに送信される隠しフィールド __EVENTTARGET に LoginStatus の UniqueID が設定される（これにより、サーバーはログイン要求であると認識するらしい）。
3. サーバーからリダイレクト指示（HTTP/1.1 302 Found）が返ってくる。応答ヘッダーに含まれる Location（リダイレクト先）は web.config で指定されたログインページ（ここでは login.aspx とする）となる。
4. リダイレクト指示を受けて、ブラウザは login.aspx を GET 要求する。
5. サーバーから応答（login.aspx）が返ってくる。
6. ユーザーが ID とパスワードを入力して［ログイン］ボタンをクリックする。
7. ［ログイン］ボタンのクリックで login.aspx にポストバックがかかる。
8. サーバーからリダイレクト指示（HTTP/1.1 302 Found）が返ってくる。応答ヘッダーに含まれる Location は default.aspx となる。この時、サーバーからの応答ヘッダーには認証クッキーが含まれる。（この時点ではロール名クッキーは送られないので注意）
9. リダイレクト指示を受けて、ブラウザは default.aspx を GET 要求する。この時、上のステップで受信した認証クッキーを要求ヘッダーに含める。
10. サーバーから応答（default.aspx）が返ってくる。認証クッキーが要求ヘッダーに含まれているので、ユーザーは認証済みとなる。（この時点で応答ヘッダーにロール名クッキーが含まれて送られてくる）

***** ログアウト *****

1. あるページ（default.aspx とする）で、ログインしている状態から LoginStatus をクリック。
2. JavaScrip でポストバック（default.aspx への POST 要求）がかかる。この時、サーバーに送信される隠しフィールド __EVENTTARGET には LoginStatus の UniqueID が設定される（これにより、サーバーはログアウト要求であると認識するらしい）。
3. サーバーからリダイレクト指示（HTTP/1.1 302 Found）が返ってくる。ただし、リダイレクト先は同一ページ（Location は default.aspx）となる。この時、認証クッキーを削除するため、応答ヘッダの Set-Cookie は、認証クッキーを空にして、expires を過去の日時に設定している。
4. ブラウザは default.aspx を GET 要求する。この前のステップの、応答ヘッダの Set-Cookie の設定により、認証クッキーは要求ヘッダーには含まれなくなる。（ただし、ロール名クッキーはこの時点ではまだ要求ヘッダーに含まれている）
5. サーバーから応答 (default.aspx) が返ってくる。ユーザーはログアウト状態となる。この時、ロール名クッキーを削除するため、応答ヘッダの Set-Cookie で、ロール名クッキーを空にして、expires を過去の日時に設定している。

なお、Windows 認証の場合は、先の記事 Windows 認証でのロール に示した Windows OS の認証ダイアログを使います。従って、Web ページにはログイン画面は実装できませんし、ログイン操作も Forms 認証とは異なります。

また、ログアウトについても、Windows 認証の場合は一旦ログインしたユーザー情報はブラウザを閉じるまで保持され続けるので、Forms 認証とは異なり、Web ページにログオフ機能は実装できません。