認証と認可の違い

なぜ分けて考えるのか

英語の頭がどちらも "Auth" で始まるせいで混同されがちですが、役割はまったく別です。

• 認証（AuthN）：通信してきた相手が本当に本人かを確かめる。ID とパスワード、ワンタイムコード、生体、OIDC などで「この人は確かに user123 だ」と特定する。詳しい仕組みは Web 認証（Cookie・セッション・JWT）。
• 認可（AuthZ）：本人だと分かった上で、この操作・このデータへのアクセスを許してよいかを判断する。「user123 は自分の注文は見られるが、他人の注文や管理画面は見られない」を決める。

ここで決定的に大事なのは、認証が通っても認可が自動的に OK になるわけではないということ。ログインは「建物に入れた」だけで、「どの部屋に入れるか」は別問題です。この一段を省くのが、後述の最も多い事故につながります。

認証 vs 認可：何が違うか

2つの違いを、観点ごとに並べます。問いの形にすると区別しやすくなります。

「タイミング」の行が実装上の肝です。認証はログイン時にまとめて済ませますが、認可はリクエストのたび、しかも触ろうとしているリソース1件ごとに判定し直す必要があります。

一番多い事故：認可の確認漏れ（IDOR）

OWASP Top 10 で**第1位がアクセス制御の不備（Broken Access Control）**です。その典型が IDOR（Insecure Direct Object Reference＝直接オブジェクト参照の不備）。「ログインさえしていればOK」として、そのデータが本当にその人のものかを確認し忘れると起きます。

// ❌ 脆弱：認証は見ているが、認可（持ち主チェック）が抜けている
app.get('/orders/:id', requireLogin, async (req, res) => {
  // ログイン済みなのは確認済み。だが「誰の注文か」を問わずに返してしまう
  const order = await db.orders.findById(req.params.id);
  res.json(order); // /orders/1002 と URL を書き換えれば他人の注文が丸見え
});

ログインユーザーが URL の :id を 1001 → 1002 と変えるだけで、他人の注文が見えてしまいます。認証は通っているのに認可をしていない、まさに混同の事故です。直し方は、取得したリソースの所有者と、認証で確定した本人が一致するかを必ず照合すること。

// ✅ 安全：認証で確定した本人と、リソースの持ち主が一致するか検証する
app.get('/orders/:id', requireLogin, async (req, res) => {
  const order = await db.orders.findById(req.params.id);
  if (!order) return res.sendStatus(404);
  // req.user.id は「認証」で確定済みの本人。これと突き合わせるのが「認可」
  if (order.userId !== req.user.id) {
    return res.sendStatus(403); // 本人だが、このリソースの権限はない
  }
  res.json(order);
});

401 と 403：どちらを返すか

混同しやすいのが 401 と 403 です。認証で落ちたのか、認可で落ちたのかで使い分けます。

紛らわしいことに、401 の名前は "Unauthorized" ですが**意味は「未認証（Unauthenticated）」**です。「認証して出直して」が 401、「あなたが誰かは分かっているが、ここは立入禁止」が 403。この区別が HTTP のステータスコード の理解とも噛み合います。

認可の設計：RBAC と ABAC

「誰が何をしてよいか」をどうルール化するかが認可の設計です。代表的なのが RBAC と ABAC の2つ。

• RBAC（Role-Based Access Control＝役割ベース）：ユーザーに「管理者」「編集者」「閲覧者」などの**役割（ロール）**を割り当て、役割に紐づく権限でアクセスを決める。「編集者は記事を書ける／閲覧者は読めるだけ」のように、役割の数だけルールを書けばよく、管理がシンプル。多くのアプリの第一選択。
• ABAC（Attribute-Based Access Control＝属性ベース）：ユーザー・リソース・状況の属性（部署・所有者・時刻・IP など）を組み合わせたポリシーで判定する。「所有者本人なら編集可」「営業時間内かつ社内ネットワークからのみ可」のような、役割だけでは表せない細かい条件を扱える。

実務ではまず RBAC を土台にし、役割だけでは表せない条件（「自分のデータだけ」など）を属性で補うハイブリッドが現実的です。先ほどの注文の例（order.userId === req.user.id）も、ロールに加えて所有者という属性で絞る ABAC 的な判定でした。

まとめ：混同しないためのチェックリスト

最後に、設計・レビューで自問すべき点を整理します。

認証と認可は、「誰か」を確かめる工程と「何ができるか」を決める工程という別々のレイヤです。認証が完璧でも認可が抜ければ穴になり、その逆も成り立ちません。具体的な方式の比較は 認証・認可の方式 に、ログイン状態の保持の仕組みは Web 認証 にまとまっています。アクセス制御を「リソースごと・サーバ側・デフォルト拒否」で組む——これが事故を防ぐ一番の近道です。