ログインの裏側
パスワードとトークンの往復で「本人」を運ぶ仕組み
ログインが一度きりで済むのは、最初の 1 回だけパスワードで本人確認し、以後は有効期限つきの「通行証（トークン）」を見せて通っているからです。
- パスワードを送るのは最初の 1 回だけ — 漏れる機会を最小にする
- 通行証は Cookie に保管され、ブラウザが毎回自動で提示する
- 通行証には期限があり、切れたら再ログイン — 漏れても被害を限定できる
なぜログインは「一度きり」で済むのか
ページを開くたびにサーバとは通信しているのに、パスワードを聞かれるのは最初だけ。その裏側で何が行き来しているのか、動く図でたどりましょう。
ログイン認証の流れ
各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
シーケンス図「ログイン認証の流れ」。参加者3人、ステップ7個。 【参加者】（左から右） - あなた: ブラウザ / アプリ - 認証サーバ: ログイン受付 - パスワード保管庫: ハッシュ照合 【流れ】（上から下へ） ── ① 認証フェーズ（最初の1回だけ） ── 1. あなた → 認証サーバ: ID とパスワードを送信 2. 認証サーバ → パスワード保管庫: 保管したハッシュと照合 3. パスワード保管庫 → 認証サーバ: 一致（本人と確認）（応答） 4. 認証サーバ → あなた: トークン（通行証）を発行（応答） 5. あなた（自身で処理）: Cookie に通行証を保管 ── ② ログイン後（2回目以降・毎回） ── （ページを開くたび繰り返し の枠） 6. あなた → 認証サーバ: 通行証を提示してアクセス 7. 認証サーバ → あなた: 通行証を検証 → データを返す（応答）
もし通行証が無かったら?
各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。
合言葉が毎回流れる — 遅いうえに、漏れる機会も毎回増える
この図をテキストで読む
シーケンス図「通行証なし（毎回パスワード）」。参加者2人、ステップ3個。 【参加者】（左から右） - あなた: ブラウザ / アプリ - サーバ: 毎回が本人確認 【流れ】（上から下へ） 1. あなた → サーバ: ページを開くたび ID とパスワードを送信 2. サーバ（自身で処理）: 毎回フル照合 3. サーバ → あなた: 応答は遅く、漏えいの機会は増える（応答）
通行証は「鍵」と同じ
トークンは、持っていれば本人として通れてしまう『鍵』です。通信は必ず暗号化（HTTPS）し、Cookie には HttpOnly / Secure の印をつけ、有効期限を短くして、万一漏れても使える時間を絞ります。
押さえておきたい用語
- 認証（Authentication）
- 「あなたが本当にその本人か」を確かめること。誰に何を許すかを決める『認可』とは別の段階。
- トークン
- 本人確認に成功したしるしとして渡される通行証。有効期限があり、切れると再ログインが必要。
- Cookie / セッション
- 通行証をブラウザにしまい自動で送る仕組みが Cookie。本体をサーバに置き、預かり番号だけ持つ方式がセッション。
- JWT
- 通行証自体に情報と改ざん防止の署名を載せて持ち歩く方式。サーバ側に保管が無くても検証できる。
- ハッシュ化
- パスワードを元に戻せない形に変換して保管する技術。保管データが漏れても合言葉そのものは守られる。
ここから先へ
この解説とつながりのあるページ