はじめに
Flaskでログイン機能を実装するときに登場するセッションの仕組みについて、PHPでセッション管理に慣れていた自分にとって、Flaskのセッションは少し不思議に思えた。
特に、「署名付きクッキー」という仕組みがなぜ安全なのか？
それがどうやって「ログイン済みの本人であることの証明」になるのか？
そして「なぜ改ざん防止が必要なのか？」という疑問について解消したので、その学びを整理する。
セッション管理の本質とは？
まず、セッション管理の目的を明確にしておく。
「リクエストが、以前ログインした人からのものかどうかを確認すること」
ログイン済みのユーザーからの操作であることを保証するために、サーバーはセッション管理を行う。
そのために使われるのが、Flaskでは「署名付きクッキー」。
Flaskのセッションの特徴
Flaskでは、session に保存したデータはサーバーではなくクライアント側（ブラウザ）にクッキーとして保存される。
ただし、それが「署名付き」であるという点がポイント。
session["user"] = "admin"
これを設定すると、Flaskは次のような手順でクッキーを作成する。
- セッションデータを JSON 形式でシリアライズ
- サーバーの
secret_keyを使って HMAC（署名）を生成 - 「データ本体 + 署名」の形式でクッキーに格納
このクッキーがクライアントに送られ、次回以降のリクエスト時に自動で送信されてくる。
なぜこれで本人確認になるのか？
署名付きクッキーは、ログイン済みのユーザーにだけに送るサーバー発行の証明書のようなもの。
サーバーは、受け取ったクッキーの中身と署名を検証し、「これは確かに自分が過去に発行したものだ」と確認できるのならば、それはつまり、ログイン済みのユーザーから送信されたクッキーであることの証明になる。
なぜ改ざんを防げるのか？
署名はセッションデータそのものから secret_key を使って生成されており、データを1文字でも書き換えると、署名と一致しなくなる。
もし user="admin" を user="guest" に書き換えても、
署名は一致しなくなる → サーバーは改ざんされたと判断して拒否する
これにより、悪意あるユーザーが自分でクッキーを書き換えて「自分はadminです」と偽装しようとしても、署名が一致しないためログイン扱いにはならない。
つまり、セッションデータそのものから署名を生成している点がポイント。
まとめ
- Flaskでは、セッションデータを署名付きクッキーとしてクライアントに送る
- 署名はセッションデータから生成されており、改ざんすれば検知される
- サーバーが署名を確認できれば、「自分が発行したクッキー」だと判断できる
- それはつまり、「ログイン済みの本人からのリクエストである」という証明になる
おわりに
Flaskの署名付きクッキーは、一見するとシンプルに思えるが、その中には「本人確認」「改ざん検出」という重要なセキュリティ要素がたくさん詰まっていることがわかった。