全社員向け / 第1章 ログインの裏側

ページ 1 / 5

第1章セキュリティ

約5分で読む

ログインの裏側

「さっきログインしたのに、なぜ次のページも開けるの?」

パスワードを毎回入れなくていい理由と、使い終わったあとの安全な使い方を見てみましょう。

  1. 01疑問

    毎回パスワード?

    毎回ではない

    ページを開くたび、パスワードを渡しているのかな?

  2. 02体験

    入力していないのに

    入力なしで続く

    さっきログインしたら、次のページも開けた!

  3. 03仕組み

    通行証を見せていた

    期限つきの通行証

    最初に受け取った通行証を、次から見せているんだ。

  4. 04納得

    通行証で続いていた

    継続と終了

    だから再入力なしで使えたんだ。使い終わったらログアウト!

この章の合言葉

ブラウザは「通行証」を持っている。使い終わったらログアウト!

※「通行証」はログイン状態を確認するための情報です。この例ではCookieで送ります。

読みはじめる

なぜログインは「一度きり」で済むのか

ページを開くたびにサーバとは通信しているのに、パスワードを聞かれるのは最初だけ。その裏側で何が行き来しているのか、動く図でたどりましょう。

ログイン認証の流れ

ページを開くたび繰り返しID とパスワードを送信ログイン要求保管したハッシュと照合本人確認一致(本人と確認)照合OKトークン(通行証)を発行通行証の発行Cookie に通行証を保管通行証の保管通行証を提示してアクセス通行証で要求通行証を検証 → データを返す検証して応答
あなたブラウザ / アプリ
認証サーバログイン受付
パスワード保管庫ハッシュ照合

各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。

この図をテキストで読む

シーケンス図「ログイン認証の流れ」。参加者3人、ステップ7個。 【参加者】(左から右) - あなた: ブラウザ / アプリ - 認証サーバ: ログイン受付 - パスワード保管庫: ハッシュ照合 【流れ】(上から下へ) ── ① 認証フェーズ(最初の1回だけ) ── 1. あなた → 認証サーバ: ID とパスワードを送信 2. 認証サーバ → パスワード保管庫: 保管したハッシュと照合 3. パスワード保管庫 → 認証サーバ: 一致(本人と確認)(応答) 4. 認証サーバ → あなた: トークン(通行証)を発行(応答) 5. あなた(自身で処理): Cookie に通行証を保管 ── ② ログイン後(2回目以降・毎回) ── (ページを開くたび繰り返し の枠) 6. あなた → 認証サーバ: 通行証を提示してアクセス 7. 認証サーバ → あなた: 通行証を検証 → データを返す(応答)

Cookieで通行証を運び、ログイン後も有効性を確認します。

もし通行証が無かったら?

ページを開くたび ID とパスワードを送信毎回ログイン毎回フル照合毎回照合応答は遅く、漏えいの機会は増える遅い応答
あなたブラウザ / アプリ
サーバ毎回が本人確認

各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。

合言葉が毎回流れる — 遅いうえに、漏れる機会も毎回増える

この図をテキストで読む

シーケンス図「通行証なし(毎回パスワード)」。参加者2人、ステップ3個。 【参加者】(左から右) - あなた: ブラウザ / アプリ - サーバ: 毎回が本人確認 【流れ】(上から下へ) 1. あなた → サーバ: ページを開くたび ID とパスワードを送信 2. サーバ(自身で処理): 毎回フル照合 3. サーバ → あなた: 応答は遅く、漏えいの機会は増える(応答)

切り替えて見比べると、通行証が「速さ」と「安全」の両方を支えているとわかります。●の速さは処理の身軽さです。

ログイン後の「通行証」も守る

共用PCでログインしたまま席を離れると、次に座った人が自分として操作できることがあります。毎回パスワードを聞かないのは、ブラウザが通行証にあたる情報を持ち、この例ではCookieで送るためです。持つだけで使える通行証は、パスワードと同じように守ります。

利用者は、使い終わったらログアウトします。設計側はCookieの削除と、サーバ側で通行証を無効にする処理を組み合わせます。JWTというデータ形式の通行証を使う場合も、失効リストなど無効化の方法をあらかじめ決めます。

設計側はHTTPSで通信を保護し、通行証の有効期限を決めます。Cookieには、スクリプトから読ませないHttpOnly、HTTPSだけで送るSecure、サイトをまたぐ送信を制限するSameSiteを設定します。本人が意図しない操作をログイン中のブラウザに送らせる攻撃(CSRF)にも、別途対策が必要です。

Cookieを消すだけでは足りない

手元のCookieを削除しても、盗まれたトークンのコピーまで失効するわけではありません。

押さえておきたい用語

認証(Authentication)
「あなたが本当にその本人か」を確かめること。誰に何を許すかを決める『認可』とは別の段階。
トークン
認証やアクセス権限に使うデータ。有効な通行証のデータを持つ人が使える方式をBearer型という。コピーも使われ得るため、期限・権限・保存先・失効を管理する。
Cookie / セッション
Cookieはブラウザが条件に従って値を保存・送信する仕組み。セッションはログイン状態の管理で、Cookieに識別子を載せる例がある。
JWT
情報を載せるトークン形式。署名付きJWTは署名・発行元・利用先・期限等を検証する。期限前の失効には別の仕組みが必要。
ハッシュ化
パスワードを平文で持たず照合するための処理。salt(利用者ごとの乱数)と適切な方式で推測を遅くするが、保管値が漏れれば候補を試される。
次に読む多要素認証(MFA)
ページ 1 / 5