バックエンド開発 / 約20分

認証(Authentication)と認可(Authorization)の違い

なぜこれを学ぶか

セキュリティ事故の多くは、認証はあるのに認可チェックが抜けているケースです。この2つを明確に区別しましょう。

認証 = 「あなたは誰か」を確認する（ログイン）。認可 = 「あなたはこれをしてよいか」を判定する（権限）。

典型的な脆弱性が IDOR（直接的なオブジェクト参照の脆弱性）です。/api/orders/123 の 123 を 124 に変えたら他人の注文が見える…という事故は、認可チェックの欠如が原因です。

対策はシンプル: すべてのリソースアクセスで「このリソースはこのユーザーのものか」を検証する。URLにIDがあるだけでは何の保証にもなりません。

「フロントでボタンを非表示にしているから安全」は間違いです。悪意あるユーザーはcurlで直接APIを叩けます。認可は必ずサーバー側で 行います。

重要ポイント

認証=誰か、認可=何をしてよいか
IDOR: URLのIDを変えるだけで他人のデータが見える事故
認可は必ずサーバー側で検証する

理解度チェック

選ぶと即座に解説が表示されます。

「マイページ画面では自分の注文へのリンクしか表示していない。API側の認可チェックは省略した」という設計の問題点は？

ヒントを見る

悪意あるユーザーはブラウザの画面だけを使うとは限りません。curl や DevTools で API を直接呼んだらどうなるか、IDOR（URLのID書き換え）の観点で考えてみましょう。

コーディング演習実際に書く

認可チェック関数を実装してください。要件: ①管理者（role が 'admin'）は全ての注文を閲覧できる ②一般ユーザーは自分の注文（order.userId と user.id が一致）のみ閲覧できる ③未ログイン（user が null）の場合は一切閲覧できない。戻り値は boolean（閲覧可: true / 不可: false）。

function canViewOrder(user, order)

模範解答（読んで理解したら、自力で書き直してみましょう）

function canViewOrder(user, order) {
  // 未ログインは一切不可
  if (!user) return false

  // 管理者は全件OK
  if (user.role === 'admin') return true

  // 一般ユーザーは自分の注文のみ
  return order.userId === user.id
}

スキルセルフチェック

このレッスンの内容をどの程度理解できましたか？

弱点マップで全体を確認する

前のレッスン次のレッスン