初級では認証を「会員証の本人確認」と捉えました。中級では、状態の持ち方・パスワード保管・委任を見ます。
中級の解説は準備中のため、中級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
これは何をする係？
ログイン後の「本人である状態」をどう持つかで、大きく2方式あります。
- セッション方式 — サーバがセッションIDを発行し、状態はサーバ側で保持。IDはCookieで持つ
- トークン方式（JWTなど） — 署名付きのトークンを発行し、状態はトークン自身に載せる（サーバはステートレスにしやすい）
アニメーション『JWTの構造』を開く
登場人物メモ:
- ※1 ソルト＋ストレッチング — ハッシュに個別のランダム値を足し、反復して重くする
- ※2 MFA — 知識（パスワード）＋所持（スマホ）＋生体、から複数を要求
仕事の流れ
- ID／パスワードで認証（パスワードはソルト＋ハッシュで照合）
- 成功したら セッションID（Cookie）または トークン（JWT） を発行
- 以降のリクエストは、Cookie またはヘッダのトークンで検証
- 重要操作では MFA を追加で要求することも
アニメーション『多要素認証の3要素（知識・所持・生体）』を開く
方式と委任
- セッション vs トークン — 取り消しやすさ（セッション）／スケールしやすさ（トークン）のトレードオフ
- パスワード保管 — 平文厳禁。ソルト＋計算コストの高いハッシュ（bcrypt/argon2 等）
- OAuth 2.0 / OIDC — アクセスの委任（OAuth）＋本人確認（OIDC）。SNSログインの正体
- パスワードレス — パスキー（生体＋端末鍵）などフィッシングに強い方式へ
アニメーション『OAuth（パスワードを渡さない委任）』を開く
- 利用者（ブラウザ） — アプリに自分のデータへのアクセスを許可したい人
- アプリ — 利用者のデータを使いたいクライアント。パスワードは受け取らない
- 認可サーバ — 本人確認と同意を担い、コードやトークンを発行する側（例: Google）
0 / 6
⚠️ うまくいかないとき
- セッション固定／ハイジャック — 印を盗まれる／固定される（HTTPS・Secure/HttpOnly・再発行で対策）
- 総当たり／クレデンシャルスタッフィング — 使い回しを突く（レート制限・MFA）
- フィッシング — 偽サイトで入力させる（パスキーが有効）
関連する知識
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 「他サービスに、必要な範囲だけアクセスを委任する」ための代表的な仕組みは？
問2. パスワードのハッシュ保存で、同じパスワードでも人ごとに違うハッシュにするために足すものは？
問3. トークン方式（JWT）がセッション方式と比べて有利になりやすい点は？
問4. 多要素認証（MFA）の「要素」の組み合わせとして正しいのは？
問5. パスワード保管の方法として適切なのはどれ？
問6. パスワードにソルトを足してからハッシュする狙いは？
問7. 認証で「知識・所持・生体」など種類の違う要素を複数要求する仕組みを、英字3文字の略語で答えてください。
問8. パスワードのハッシュを繰り返し計算して総当たりを重くする処理を、カタカナで何と呼びますか。