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

パスワードそのものの保管（ソルト・ストレッチング・Argon2 など）の詳細は、パスワードはどう守られているのか と ハッシュ を参照。ここからはログイン後の「本人である状態」の管理を深掘りします。

「ログイン中」を支えるセッションは、発行・保持・失効の各所に勘所があります。

• 推測不能なID発行 — セッションIDは CSPRNG（暗号論的に安全な乱数）で十分な長さにする。連番や時刻由来は厳禁
• サーバ側ストア — 状態はサーバ側（Redis 等）に持ち、Cookie にはIDだけを載せる。中身をクライアントに晒さない
• 固定化対策 — ログイン成功の瞬間にセッションIDを再発行する（攻撃者が用意したIDを使わせるセッション固定攻撃を無効化）
• 二重の有効期限 — 無操作での失効（アイドルタイムアウト）と、発行からの上限（絶対タイムアウト）を併用する
• 即時失効 — サーバ側ストアを消せば、ログアウトや「全端末からサインアウト」が即座に効く（ステートレスなトークン方式にはない強み）
• Cookie属性 — HttpOnly（ページ内JSから隔離）／Secure（暗号化経路でのみ送出）／SameSite（別サイト起点の自動送信を抑止しCSRF対策）

1. 署名検証 — JWTは署名（HMAC／RSA／ECDSA）を必ず検証。alg固定、鍵ID（kid）で鍵を選ぶ
2. 鍵ローテーション — 署名鍵を定期更新。JWKSで公開鍵を配る
3. 失効の難しさ — ステートレスなトークンは取り消しにくい。短命化＋リフレッシュトークン、失効リストで補う
4. OAuth 2.0（認可コード＋PKCE） — フロントに秘密を置かず、コードを短命に交換。PKCEで横取りを防ぐ
5. OIDC — OAuthの上に「本人確認（IDトークン）」を乗せる

• WebAuthn／FIDO2（パスキー） — 公開鍵のチャレンジ-レスポンス。端末が秘密鍵を持ち、署名はオリジンに紐づく
• フィッシング耐性 — 署名が正規サイト向けなので、偽サイトでは通らない
• デバイスバウンド vs 同期パスキー — 鍵が端末外に出ない方式（デバイスバウンド。耐タンパ性が高い）と、プロバイダのクラウド経由で端末間同期する方式（同期パスキー。機種変更に強いが鍵が端末外に出る＝可用性と耐タンパ性のトレードオフ）
• 多要素の質 — 「所持（端末）＋生体」で、SMSコードより強い

• alg=none／アルゴリズム混同 — 署名検証の実装ミスで改ざんを通す
• トークン漏洩・リプレイ — 保存場所（HttpOnly Cookie）と有効期限、バインディング
• OAuthのリダイレクト詐取 — redirect_uri厳格化、stateでCSRF対策
• クレデンシャルスタッフィング — 使い回しを突く。レート制限・パスキー・漏洩パスワード照合