チェックポイント：OAuth/JWTを実装しよう

クイズの説明

Step 4で学んだ内容の理解度をチェックします。

全8問
合格ライン: 80%（7問正解）
不合格の場合は復習してから再挑戦してください

問題

Q1. 認証（Authentication）と認可（Authorization）の違いとして正しいものはどれですか？

A) 認証は権限のチェック、認可は本人確認
B) 認証は本人確認、認可は権限のチェック
C) 認証と認可は同じ意味である
D) 認証はサーバーサイド、認可はクライアントサイドで行う

<details> <summary>答えを見る</summary>

正解: B

認証（Authentication）: 「あなたは誰？」= 本人であることを確認するプロセス
認可（Authorization）: 「あなたは何ができる？」= 認証されたユーザーに対して、どの操作を許可するかを制御するプロセス

認証は常に認可の前に行われます。まず本人確認（認証）をして、次に権限確認（認可）をします。

</details>

Q2. パスワードの保存方法として最も安全なものはどれですか？

A) AES暗号化して保存する
B) SHA-256でハッシュ化して保存する
C) bcryptでソルト付きハッシュ化して保存する
D) Base64エンコードして保存する

<details> <summary>答えを見る</summary>

正解: C

A（AES暗号化）: 鍵があれば復号できるため、鍵が漏洩するとパスワードが復元される
B（SHA-256）: 高速すぎるためブルートフォース攻撃に弱い。ソルトも自動付加されない
C（bcrypt）: パスワードハッシュ用に設計。意図的に低速で、ソルトを自動生成。推奨
D（Base64）: エンコードであり暗号化ではない。誰でもデコードできる

</details>

Q3. JWTのペイロードについて正しいものはどれですか？

A) ペイロードは暗号化されており、秘密鍵がないと読めない
B) ペイロードはBase64Urlエンコードされており、誰でもデコードして読める
C) ペイロードにはパスワードを含めるのが一般的である
D) ペイロードはサーバーサイドにのみ存在し、クライアントには送信されない

<details> <summary>答えを見る</summary>

正解: B

JWTのペイロードはBase64Urlでエンコードされているだけで、暗号化はされていません。誰でもデコードして中身を読むことができます。

そのため、パスワード、クレジットカード番号などの機密情報をペイロードに含めてはいけません。 JWTの署名は「改ざんの検出」のためであり、「内容の秘匿」のためではありません。

</details>

Q4. アクセストークンとリフレッシュトークンの関係として正しいものはどれですか？

A) アクセストークンは長期間有効で、リフレッシュトークンは短期間有効
B) アクセストークンは短期間有効で、リフレッシュトークンは新しいアクセストークンの取得に使う
C) 両方とも同じ有効期限で、どちらもAPIアクセスに使える
D) リフレッシュトークンはアクセストークンの暗号化版である

<details> <summary>答えを見る</summary>

正解: B

アクセストークン: 短い有効期限（15分程度）。APIへのアクセスに使用
リフレッシュトークン: 長い有効期限（7日程度）。期限切れのアクセストークンを新しく発行するために使用

この仕組みにより、アクセストークンが盗まれても被害期間が限定される一方、ユーザーは長期間ログイン状態を維持できます。

</details>

Q5. OAuth 2.0の認可コードフローで、認可コードをアクセストークンに交換する処理はどこで行うべきですか？

A) ブラウザ（クライアントサイド）
B) サーバーサイド（バックエンド）
C) 認可サーバー
D) どこで行っても安全である

<details> <summary>答えを見る</summary>

正解: B

認可コードからアクセストークンへの交換には client_secret が必要です。 client_secret はクライアント（ブラウザ）に公開してはいけないため、必ずサーバーサイド（バックエンド）で行う必要があります。

ブラウザで実行すると、client_secret がソースコードやネットワーク通信から漏洩します。

</details>

Q6. RBACで、一般ユーザーが管理者のデータを閲覧できてしまう脆弱性の名前はどれですか？

A) SQLインジェクション
B) IDOR（Insecure Direct Object Reference）
C) CSRF
D) XSS

<details> <summary>答えを見る</summary>

正解: B

IDOR（Insecure Direct Object Reference） は、認可チェックが不十分なために、 URLのパラメータ（/api/users/123）を別のIDに変更するだけで他人のリソースにアクセスできてしまう脆弱性です。

例: /api/users/1/profile で自分のプロフィールを見た後、 /api/users/2/profile に変更して他人のプロフィールが見れてしまう。

対策: リソースの所有者チェック（認可チェック）を実装する。

</details>

Q7. JWTの署名アルゴリズムを明示的に指定する理由はどれですか？

A) パフォーマンスを向上させるため
B) "none" アルゴリズム攻撃を防ぐため
C) トークンのサイズを小さくするため
D) ペイロードを暗号化するため

<details> <summary>答えを見る</summary>

正解: B

JWTの仕様では "alg": "none" というアルゴリズムが定義されており、署名なしのトークンを作成できます。

攻撃者がヘッダーのアルゴリズムを none に変更し、署名を空にしたトークンを送信すると、アルゴリズムを検証していないサーバーでは改ざんされたトークンが有効と判定されます。

jwt.verify(token, secret, { algorithms: ['HS256'] }) のように許可するアルゴリズムを明示的に指定することで、この攻撃を防げます。

</details>

Q8. OAuth 2.0の state パラメータの目的はどれですか？

A) ユーザーのセッション状態を保存する
B) CSRF攻撃を防ぐためのランダムな値
C) アクセストークンの有効期限を指定する
D) リダイレクトURLを暗号化する

<details> <summary>答えを見る</summary>

正解: B

state パラメータは CSRF 攻撃を防ぐためのランダムな値です。

クライアントがランダムな state 値を生成してセッションに保存
認可リクエストに state を含めて送信
コールバックで返された state とセッションに保存した値を比較
一致しなければリクエストを拒否

これにより、攻撃者が偽の認可コードを含むURLを使ってユーザーのアカウントと攻撃者のアカウントを紐づけることを防げます。

</details>

結果

7問以上正解の場合

合格です。おめでとうございます。

Step 4「OAuth/JWTを実装しよう」を完了しました。次は Step 5「セキュリティツールを導入しよう」に進みましょう。

6問以下の場合

もう少し復習しましょう。

問題	復習セクション
Q1, Q6	step4_1 認証と認可の違い
Q2	step4_2 パスワードの安全な管理
Q3, Q4, Q7	step4_3 JWTの仕組み
Q5, Q8	step4_4 OAuth 2.0フロー

Step 4 完了

お疲れさまでした。

学んだこと

認証と認可の違い、セッション vs トークン
bcryptによるパスワードの安全な管理
JWTの構造、発行、検証、リフレッシュ
OAuth 2.0の認可コードフロー
ロールベースアクセス制御（RBAC）

次のステップ

Step 5: セキュリティツールを導入しよう（3時間）

コードの安全性を自動的に検証するツール群をCI/CDに組み込む方法を学びます。

推定所要時間: 30分