理Kotowary

認証（ログインシステム）— 「あなたは誰？」を確かめる

大人こども
初級中級上級

概要 — まず全体をつかむ

ログインの入口でまず行うのが認証。「あなたは誰？」を確かめる仕組みです。

パスワードそのものの守られ方（届ける→ハッシュ化して保管→照合）は パスワードはどう守られているのか を参照。ここではログインシステム全体を扱います。

詳細 — 1段階ずつ追う

これは何をする係？

会員証を見せて本人確認するのと同じ。多くは ID（メール等）＋パスワード（※1 合言葉） で確かめます。合っていれば「ログイン中」の印（※2 セッション）を渡し、以降はその印で本人と判断します。

登場人物メモ:

  • ※1 パスワード — 本人だけが知っている合言葉
  • ※2 セッション — 「ログイン中」を示す印。多くは Cookie に保存される
この部分をもっと深く（中級）

ログイン後の「本人である状態」をどう持つかで、大きく2方式あります。

  • セッション方式 — サーバがセッションIDを発行し、状態はサーバ側で保持。IDはCookieで持つ
  • トークン方式（JWTなど） — 署名付きのトークンを発行し、状態はトークン自身に載せる（サーバはステートレスにしやすい）
アニメーション『JWTの構造』を開く
JWTの構造 — ドット（.）で3つに分かれる1本のトークン xxxxx . yyyyy . zzzzz. 区切り. 区切りxxxxx① ヘッダ署名の方式など{ "alg": "HS256", "typ": "JWT"}yyyyy② ペイロード（クレーム）載せたいデータ{ "sub": "user-123", "name": "Taro", "exp": 1699999999}zzzzz③ 署名改ざん検知の要HMAC-SHA256( base64(ヘッダ)+"." +base64(ペイロード), 秘密鍵)署名で「改ざん」は検知できる。ただし中身は誰でも読める（Base64は暗号ではない）ので、パスワード等の秘密情報は入れない。

登場人物メモ:

  • ※1 ソルト＋ストレッチング — ハッシュに個別のランダム値を足し、反復して重くする
  • ※2 MFA — 知識（パスワード）＋所持（スマホ）＋生体、から複数を要求

仕事の流れ

  1. ID とパスワードを入力する
  2. サーバが、保存してある情報と突き合わせる（照合）
  3. 合っていれば「ログイン中」の印（セッション）を発行して渡す
  4. 以降のアクセスは、その印で「本人だ」と判断する
この部分をもっと深く（中級）
  1. ID／パスワードで認証（パスワードはソルト＋ハッシュで照合）
  2. 成功したら セッションID（Cookie）または トークン（JWT） を発行
  3. 以降のリクエストは、Cookie またはヘッダのトークンで検証
  4. 重要操作では MFA を追加で要求することも
アニメーション『多要素認証の3要素（知識・所持・生体）』を開く
多要素認証（MFA）の3要素「知っている」「持っている」「本人の身体」——種類の違う証拠🔑知識Something you knowパスワードPIN秘密の質問📱所持Something you haveスマホ（ワンタイムコード）セキュリティキーICカード🧬生体Something you are指紋顔虹彩異なるカテゴリを2つ以上 組み合わせると強い同じカテゴリを2つ重ねても弱い（例：パスワード＋秘密の質問＝どちらも「知識」）。知識＋所持のように“種類の違う”証拠を混ぜると、片方が漏れても突破されにくい。例：🔑 知識（パスワード）＋ 📱 所持（スマホのコード）

守るための工夫

  • パスワードはそのまま保存しない — ハッシュ化（元に戻せない形）して保管する
  • 多要素認証（MFA） — パスワードに加えて、スマホの確認コードなど「もう1つ」を要求
  • SNSログイン — 他サービスの認証を借りる（自分でパスワードを預からない）
ハードウェアセキュリティキー
所持による本人確認（パスキー/MFA）
この部分をもっと深く（中級）
  • セッション vs トークン — 取り消しやすさ（セッション）／スケールしやすさ（トークン）のトレードオフ
  • パスワード保管 — 平文厳禁。ソルト＋計算コストの高いハッシュ（bcrypt/argon2 等）
  • OAuth 2.0 / OIDC — アクセスの委任（OAuth）＋本人確認（OIDC）。SNSログインの正体
  • パスワードレス — パスキー（生体＋端末鍵）などフィッシングに強い方式へ
アニメーション『OAuth（パスワードを渡さない委任）』を開く
利用者（ブラウザ）アプリ認可サーバ
  • 利用者（ブラウザ） — アプリに自分のデータへのアクセスを許可したい人
  • アプリ — 利用者のデータを使いたいクライアント。パスワードは受け取らない
  • 認可サーバ — 本人確認と同意を担い、コードやトークンを発行する側（例: Google）
「▶ 再生」で通しで見るか、「次へ」で1手ずつ進めてください。
0 / 6

⚠️ うまくいかないとき

  • パスワードの使い回し・漏洩 — 他サイトの流出で芋づる式に破られる
  • なりすまし — 印（セッション）を盗まれて本人のふりをされる
  • 総当たり — パスワードを機械的に試される（回数制限で防ぐ）
この部分をもっと深く（中級）
  • セッション固定／ハイジャック — 印を盗まれる／固定される（HTTPS・Secure/HttpOnly・再発行で対策）
  • 総当たり／クレデンシャルスタッフィング — 使い回しを突く（レート制限・MFA）
  • フィッシング — 偽サイトで入力させる（パスキーが有効）

関連する知識

理解度チェック

そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。

問1. サービスがパスワードを保存するとき、安全なのは？

問2. 認証（Authentication）が確かめているのは？

問3. 「あなたが誰か（本人かどうか）」を確かめることを、日本語二文字の熟語で何と言いますか。

問4. 「ログイン中」であることを示す印で、多くはCookieに保存されるものを何と呼びますか。カタカナで答えてください。

問5. ログインに成功したあと、以降のアクセスで「本人だ」と判断するために渡される印はどれ？

問6. 多要素認証（MFA）の例として近いのは？

問7. 「SNSログイン（他サービスの認証を借りる）」の利点に近いのは？

問8. 総当たり（パスワードを機械的に次々試す攻撃）を防ぐのに有効なのは？