初級では認証を「会員証の本人確認」と捉えました。中級では、状態の持ち方・パスワード保管・委任を見ます。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
これは何をする係？
ログイン後の「本人である状態」をどう持つかで、大きく2方式あります。
- セッション方式 — サーバがセッションIDを発行し、状態はサーバ側で保持。IDはCookieで持つ
- トークン方式（JWTなど） — 署名付きのトークンを発行し、状態はトークン自身に載せる（サーバはステートレスにしやすい）
アニメーション『JWTの構造』を開く
登場人物メモ:
- ※1 ソルト＋ストレッチング — ハッシュに個別のランダム値を足し、反復して重くする
- ※2 MFA — 知識（パスワード）＋所持（スマホ）＋生体、から複数を要求
この部分をもっと深く（上級）
パスワードそのものの保管（ソルト・ストレッチング・Argon2 など）の詳細は、パスワードはどう守られているのか と ハッシュ を参照。ここからはログイン後の「本人である状態」の管理を深掘りします。
「ログイン中」を支えるセッションは、発行・保持・失効の各所に勘所があります。
- 推測不能なID発行 — セッションIDは CSPRNG（暗号論的に安全な乱数）で十分な長さにする。連番や時刻由来は厳禁
- サーバ側ストア — 状態はサーバ側（Redis 等）に持ち、Cookie にはIDだけを載せる。中身をクライアントに晒さない
- 固定化対策 — ログイン成功の瞬間にセッションIDを再発行する（攻撃者が用意したIDを使わせるセッション固定攻撃を無効化）
- 二重の有効期限 — 無操作での失効（アイドルタイムアウト）と、発行からの上限（絶対タイムアウト）を併用する
- 即時失効 — サーバ側ストアを消せば、ログアウトや「全端末からサインアウト」が即座に効く（ステートレスなトークン方式にはない強み）
- Cookie属性 — HttpOnly（ページ内JSから隔離）／Secure（暗号化経路でのみ送出）／SameSite（別サイト起点の自動送信を抑止しCSRF対策）
やさしく言うと（初級）
会員証を見せて本人確認するのと同じ。多くは ID（メール等）＋パスワード（※1 合言葉） で確かめます。合っていれば「ログイン中」の印（※2 セッション）を渡し、以降はその印で本人と判断します。
登場人物メモ:
- ※1 パスワード — 本人だけが知っている合言葉
- ※2 セッション — 「ログイン中」を示す印。多くは Cookie に保存される
仕事の流れ
- ID／パスワードで認証（パスワードはソルト＋ハッシュで照合）
- 成功したら セッションID（Cookie）または トークン（JWT） を発行
- 以降のリクエストは、Cookie またはヘッダのトークンで検証
- 重要操作では MFA を追加で要求することも
アニメーション『多要素認証の3要素（知識・所持・生体）』を開く
この部分をもっと深く（上級）
- 署名検証 — JWTは署名（HMAC／RSA／ECDSA）を必ず検証。alg固定、鍵ID（kid）で鍵を選ぶ
- 鍵ローテーション — 署名鍵を定期更新。JWKSで公開鍵を配る
- 失効の難しさ — ステートレスなトークンは取り消しにくい。短命化＋リフレッシュトークン、失効リストで補う
- OAuth 2.0（認可コード＋PKCE） — フロントに秘密を置かず、コードを短命に交換。PKCEで横取りを防ぐ
- OIDC — OAuthの上に「本人確認（IDトークン）」を乗せる
やさしく言うと（初級）
- ID とパスワードを入力する
- サーバが、保存してある情報と突き合わせる（照合）
- 合っていれば「ログイン中」の印（セッション）を発行して渡す
- 以降のアクセスは、その印で「本人だ」と判断する
方式と委任
- セッション vs トークン — 取り消しやすさ（セッション）／スケールしやすさ（トークン）のトレードオフ
- パスワード保管 — 平文厳禁。ソルト＋計算コストの高いハッシュ（bcrypt/argon2 等）
- OAuth 2.0 / OIDC — アクセスの委任（OAuth）＋本人確認（OIDC）。SNSログインの正体
- パスワードレス — パスキー（生体＋端末鍵）などフィッシングに強い方式へ
アニメーション『OAuth（パスワードを渡さない委任）』を開く
- 利用者（ブラウザ） — アプリに自分のデータへのアクセスを許可したい人
- アプリ — 利用者のデータを使いたいクライアント。パスワードは受け取らない
- 認可サーバ — 本人確認と同意を担い、コードやトークンを発行する側（例: Google）
0 / 6
この部分をもっと深く（上級）
- WebAuthn／FIDO2（パスキー） — 公開鍵のチャレンジ-レスポンス。端末が秘密鍵を持ち、署名はオリジンに紐づく
- フィッシング耐性 — 署名が正規サイト向けなので、偽サイトでは通らない
- デバイスバウンド vs 同期パスキー — 鍵が端末外に出ない方式（デバイスバウンド。耐タンパ性が高い）と、プロバイダのクラウド経由で端末間同期する方式（同期パスキー。機種変更に強いが鍵が端末外に出る＝可用性と耐タンパ性のトレードオフ）
- 多要素の質 — 「所持（端末）＋生体」で、SMSコードより強い
やさしく言うと（初級）
- パスワードはそのまま保存しない — ハッシュ化（元に戻せない形）して保管する
- 多要素認証（MFA） — パスワードに加えて、スマホの確認コードなど「もう1つ」を要求
- SNSログイン — 他サービスの認証を借りる（自分でパスワードを預からない）
⚠️ うまくいかないとき
- セッション固定／ハイジャック — 印を盗まれる／固定される（HTTPS・Secure/HttpOnly・再発行で対策）
- 総当たり／クレデンシャルスタッフィング — 使い回しを突く（レート制限・MFA）
- フィッシング — 偽サイトで入力させる（パスキーが有効）
この部分をもっと深く（上級）
- alg=none／アルゴリズム混同 — 署名検証の実装ミスで改ざんを通す
- トークン漏洩・リプレイ — 保存場所（HttpOnly Cookie）と有効期限、バインディング
- OAuthのリダイレクト詐取 — redirect_uri厳格化、stateでCSRF対策
- クレデンシャルスタッフィング — 使い回しを突く。レート制限・パスキー・漏洩パスワード照合
やさしく言うと（初級）
- パスワードの使い回し・漏洩 — 他サイトの流出で芋づる式に破られる
- なりすまし — 印（セッション）を盗まれて本人のふりをされる
- 総当たり — パスワードを機械的に試される（回数制限で防ぐ）
関連する知識
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 「他サービスに、必要な範囲だけアクセスを委任する」ための代表的な仕組みは？
問2. パスワードのハッシュ保存で、同じパスワードでも人ごとに違うハッシュにするために足すものは？
問3. トークン方式（JWT）がセッション方式と比べて有利になりやすい点は？
問4. 多要素認証（MFA）の「要素」の組み合わせとして正しいのは？
問5. パスワード保管の方法として適切なのはどれ？
問6. パスワードにソルトを足してからハッシュする狙いは？
問7. 認証で「知識・所持・生体」など種類の違う要素を複数要求する仕組みを、英字3文字の略語で答えてください。
問8. パスワードのハッシュを繰り返し計算して総当たりを重くする処理を、カタカナで何と呼びますか。