初級では認可を「入れる部屋は役職次第」と捉えました。中級では、制御モデルと、サーバ側での必須確認を見ます。
中級の解説は準備中のため、中級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
これは何をする係？
権限の決め方には代表的な2方式があります。
- RBAC（ロールベース） — 「管理者・編集者・閲覧者」などロールに権限を束ね、利用者に割り当てる
- ABAC（属性ベース） — 部署・所有者・時間帯などの属性で、より細かく判断する
登場人物メモ:
- ※1 スコープ — トークンに載る「できる操作の範囲」（OAuth）
- ※2 所有者チェック — 「そのデータの持ち主か」を確認すること
アニメーション『RBAC（ロールで権限を束ねる）』を開く
仕事の流れ
- 認証で「誰か」を特定する
- リクエストのたびに ポリシー評価（ロール／属性／所有者）
- サーバ側で許可・拒否を判断する（クライアントの制御は飾りに過ぎない）
- 拒否なら 403 を返す
設計の勘所
- RBAC vs ABAC — まずRBAC、細かい制御が要ればABACを足す
- 垂直と水平 — 垂直＝上位権限への昇格を防ぐ／水平＝他人の同種データへの越境を防ぐ
- スコープで範囲を絞る — OAuthではトークンのスコープで「できる操作の範囲」を限定する（※1）
- 最小権限 — 既定は拒否（deny by default）、必要な分だけ許可
- サーバで必ず確認 — 画面でボタンを隠すのはUXであって認可ではない
⚠️ うまくいかないとき
- IDOR — IDを差し替えるだけで他人のデータにアクセスできる（所有者チェック漏れ）
- 認可漏れ — 一部のAPIだけチェックを忘れる
- 権限昇格 — ロールや属性の判定ミスで上位操作ができてしまう
関連する知識
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 「役割（ロール）に権限をまとめ、利用者にロールを割り当てる」方式はどれ？
問2. URLのIDを他人のものに変えると、他人のデータが見えてしまう脆弱性は？
問3. 「既定は拒否し、必要な分だけ許可する」という原則を何と呼ぶ？
問4. OAuthのトークンに載る「できる操作の範囲」を何と呼びますか。カタカナで答えてください。
問5. 認証で「誰か」を特定した後に「何をしてよいか」を決める仕組みを、日本語二文字で何と言いますか。
問6. 認可でリクエストを拒否したとき、返すのに適したHTTPステータスはどれ？
問7. 「画面でボタンを隠す」ことは認可として十分か？
問8. 「水平方向の権限越境」に当たるのはどれ？