認証・認可 | Security Atlas

先に読むと理解しやすい記事：HTTP・HTTPS

認証は誰か、認可は何をしてよいかを確かめる

認証は、提示されたパスワードや鍵などを検証し、どのアカウントや機械として扱うかを確かめる処理です。認可は、その利用者が要求したデータや操作を許可されているか判断する処理です。

Aさんがログインしても、Bさんの請求書を読めるとは限りません。サーバーはAさんと特定する認証の結果を使い、請求書の所有者や共有権限を調べて閲覧を認可します。

パスワードでログインできることは、そのアカウントの認証情報を使えることの確認です。それだけで戸籍上の氏名や入力した住所が真実だと保証するわけではありません。現実の人物との対応を確かめる手続きは、目的に応じて別途必要になります。

利用者名をリクエストに含めただけでも認証にはなりません。サーバーが検証したセッションやトークンから利用者を決めます。自由に書き換えられるuserIdを、そのまま認証済みのIDとして使わないようにします。

認可では「Aさんは請求書42を読めるか」のように、主体、対象、操作を組み合わせます。閲覧できても削除できない、といった違いも扱います。ログイン済みかを見るだけでは足りません。

役割で権限を決める方法をRBACと呼びます。管理者や一般利用者という役割を使います。所属組織や所有者との関係も条件にできます。複数組織で使うサービスでは、役割だけでなく対象が同じ組織に属するかも確認します。

仮定の例として、Aさんが /invoices/42 を /invoices/43 に変えます。サーバーがログイン済みかだけを確認し、所有者を調べず43番を返すと、AさんはBさんの住所や請求額を取得できます。認証を突破しなくても成立する認可の不備です。

サーバーは認証結果から利用者IDを取得し、その利用者が閲覧できる請求書から指定IDを検索します。ランダムなIDに変えるだけでは、共有URLやログからIDを知った相手の不正閲覧を防げません。

管理者以外に削除ボタンを表示しなくても、攻撃者はAPIへ直接リクエストを作れます。削除API自身が、認証情報と対象の権限を毎回確認します。

許可ルールがなければ拒否する設計を基本にします。ファイル配信や一括処理にも確認が必要です。権限確認に成功しても、操作を本人が意図したかを確認するCSRF対策は別の役割として残ります。

確認問題：正しいJWTを持つ利用者なら、APIの全注文を取得してよいでしょうか。答えは違います。トークンの検証と、各注文への閲覧許可の判断が必要です。

自分の検証環境で、同じ役割の別アカウント、別組織のアカウント、未ログインの状態を使います。正規操作の成功に加えて、対象と利用者の組み合わせを変えると拒否されるか確認します。

未確認事項・限界

通信例・設定例・被害の例は、仕組みを理解するための仮定です。特定の製品で発生した事件を示すものではありません。ブラウザやサービス固有の設定は、利用する環境の公式資料でも確認してください。