前回との接続——本人確認を次の通信へ引き継ぐ
前回のQ-02では、パスワードをハッシュにして保存し、平文で持たないという守り方を学びました。無事にログインできたとして、問題はその後です。Webは1回ごとの通信が独立しているため、放っておけばページを移るたびに誰だか分からなくなります。この講義では、いちど確認した本人確認を次の通信へどう引き継ぐのか、そしてそれをどう断ち切るのかを扱います。
このスライドのポイント
- Q-02: パスワードはハッシュで保存し、平文で持たない
- ログインが通ったあとの問題: Webは1回ごとの通信が独立している
- この講義の役割: いちど確認した本人確認を、次の通信へどう引き継ぎ、どう断ち切るか
2つの方式の定義
ログインを続ける方法には、大きく2つあります。1つ目のセッション方式は、誰がログイン中かという状態をサーバー側に持ち、ブラウザにはその状態を指し示すIDだけをCookieで渡します。D-07で見た、毎回の通信に乗る身分証のうち、中身はサーバーが握る形です。2つ目のトークン方式は、署名付きの証明書そのものをブラウザに渡し、サーバーは受け取るたびに署名を検証するだけです。状態をサーバーに持たない、J-10で学んだ考え方の認証版といえます。
このスライドのポイント
- セッション方式: 状態をサーバー側（DB等）に持ち、ブラウザには状態を指すIDだけをCookie（D-07）で渡す
- トークン方式: 署名付きの証明書そのものをブラウザに渡し、サーバーは受け取るたびに検証するだけ
- どちらもD-07の「毎回のリクエストに乗る身分証」の実装
- トークン方式は状態をサーバーに持たない（J-10のステートレス設計の認証版）
なぜ必要か——失効設計の欠落に気づくために
この違いを知らないと、失効の設計が抜けていることに気づけません。たとえば、ログアウトしたはずなのに古い身分証が使い回せてしまう、退職した人のアクセスをその場で断ち切れない、といった穴です。AIに認証機能を作らせたとき、それがどちらの方式で、いざというときに止められるのかを評価できなければ、危険を見逃します。方式の名前を覚えることより、止められるかどうかを見る目が大切です。
このスライドのポイント
- 知らないと気づけない穴: ログアウトしたのに古い身分証が使い回せる
- 退職した人のアクセスをその場で断ち切れない
- AIが生成した認証コードの方式と「止められるか」を評価できない
構造——3つの観点で見比べる
2つの方式は、3つの観点で見比べると構造がつかめます。1つ目は状態の置き場所です。セッション方式はサーバー側、トークン方式はブラウザ側に置きます。2つ目は照合の方法で、前者はサーバーの記録と照らし合わせ、後者は署名を検証します。3つ目が失効のしやすさです。状態をサーバーが握っていれば、それを消すだけで止められます。J-10で扱った状態の置き場所の議論が、そのまま安全性の話として戻ってきます。
このスライドのポイント
- 観点1: 状態の置き場所（サーバー側かブラウザ側か）
- 観点2: 照合方法（記録と突き合わせるか、署名を検証するか）
- 観点3: 失効のしやすさ（状態を消せるかどうか）
- J-10で扱った「状態の置き場所」の議論が、安全性の話として戻ってくる
処理の流れ——退職者のアクセスを止める
経費アプリで考えます。ある社員が退職し、その瞬間から経費データへのアクセスを止めたいとします。セッション方式なら、サーバー側の状態を削除すれば、次の通信からもう通りません。トークン方式では、すでに渡した証明書は有効期限が切れるまで生き続けます。だからトークン方式では、有効期限をあらかじめ短く設定し、期限が来たら取り直す仕組みと組み合わせて、止まるまでの時間を縮めます。
このスライドのポイント
- 経費アプリ: ある社員が退職、その瞬間から経費データへのアクセスを止めたい
- セッション方式: サーバー側の状態を削除すれば、次の通信からもう通らない
- トークン方式: すでに渡した証明書は有効期限が切れるまで有効
- だからトークン方式は有効期限を短くし、取り直す仕組みと組み合わせる
技術サンプル——2方式の比較表
こちらが2つの方式の比較表です。読むときの勘どころは2つあります。1つは状態の場所の列で、ここが失効のしやすさを決めています。もう1つは、どちらの方式でもブラウザに渡すものは身分証だという点です。中身がIDなのか証明書そのものなのかが違うだけで、通信のたびに提示される役割は同じです。向く場面の列は絶対の正解ではなく、失効の要件しだいで選ぶ、という読み方をしてください。
このスライドのポイント
- 種別: table
- 目的: セッション方式とトークン方式を、状態の場所・ブラウザに渡すもの・失効・向く場面で比較する
混同しやすい概念——ログアウト vs 失効
ここでいちばん間違えやすいのが、ログアウトと失効の違いです。ログアウトは、多くの場合ブラウザ側から身分証を捨てて画面上でログイン状態を消す操作にすぎません。身分証そのものがサーバー側で無効になっていなければ、同じ証明書を持ち出せば、まだ通ってしまいます。画面から消えたことと、使えなくなったことは別物です。本当に守るための本体は、失効、つまりサーバー側で無効にできることのほうです。
このスライドのポイント
- ログアウト: 多くの場合ブラウザ側で身分証を捨て、画面上のログイン状態を消すだけ
- 失効: サーバー側で身分証そのものを無効にすること
- 画面から消えたことと、使えなくなったことは別物
- 守るための本体は「失効」のほう
バイブコーディングでの確認点
AIに認証まわりを作らせたら、2つの質問を定型にして確認してください。1つ目は「有効期限は何分ですか」。2つ目は「管理者が特定の利用者を即時に失効できますか」。この2問に明確に答えられない実装は、退職者や紛失した端末への備えが弱いと考えられます。方式を選ぶより先に、止められるかどうかを確かめる習慣を持ってください。
このスライドのポイント
- 認証まわりを作らせたら、2つの質問を定型にする
- 質問1: 「有効期限は何分ですか」
- 質問2: 「管理者が特定の利用者を即時に失効できますか」
- 明確に答えられない実装は、退職者や紛失端末への備えが弱い
まとめと一問一答
最後に1問です。即時の失効が得意なのは、どちらの方式でしょうか。……答えは、セッション方式です。状態がサーバー側にあるので、それを消せばすぐに止められます。30秒でまとめます。ログインの継続には状態をサーバーに持つセッション方式と、証明書をブラウザに渡すトークン方式があり、選ぶ基準は失効できるかどうかです。ログアウトと失効は別物でした。次回は、自分でパスワードを預からずに済む外部ログインへ進みます。関連資料は「AIアプリのセキュリティ超入門」と「Supabase入門ハンドブック」です。
このスライドのポイント
- 一問一答: 即時の失効が得意なのはどちらの方式か → セッション方式
- 30秒まとめ: 継続の2方式（状態はサーバーかブラウザか）、選ぶ基準は失効できるか、ログアウトと失効は別物
- 次回: 自分でパスワードを預からない外部ログインへ
- 関連資料: 「AIアプリのセキュリティ超入門」「Supabase入門ハンドブック」
