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