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