認証と認可 ―「誰か」と「何をしてよいか」を分ける

ログイン済みなのに編集を拒否するのはなぜ？一つのリクエストを追い、認証・所有者確認・APIの認可を図解します。

同じログインでも、できることは違う

アニメモにログインしたアオイさんが、ある教材の編集ボタンを押しました。ログインは成功しています。それでも、その教材が別の人の作品なら編集を許してはいけません。

ここには二つの問いがあります。認証は「あなたは誰か」、認可は「その操作を許してよいか」。図の人物カードが二つの関門を進む様子を追ってみてください。

「ログイン済みだから全部OK」と考えると、他人の作品を書き換える穴が生まれます。OWASPの認可ガイドも、この区別を出発点にしています。

まず、アオイさんがアカウントの認証手段を持つことを確認します。パスワード、パスキー、外部の認証サービスなどは、そのための手段です。

認証結果からアプリが得るのは「このリクエストは利用者Aとして扱える」という情報です。人間の実名や法的な身元まで必ず確認する、という意味ではありません。

ログイン後のリクエストでも、サーバーはセッションやトークンを検証します。フォームから送られた user_id: "A" という自己申告だけでは主語を決めません。

認証で利用者Aと分かったら、次は対象の作品と操作を照合します。「作品Xの所有者がA」かつ「編集が許される状態」なら、編集を許可できます。

同じ人でも対象や操作が変われば答えは変わります。図では、同じ人物カードを保ったまま判定先が変わります。

アオイさんが作品IDをXからYへ書き換えたとします。ログイン情報は同じでも、Yが他人の非公開作品ならアクセスを拒否します。

画面の編集ボタンを隠すだけでは防げません。ブラウザの開発者ツールや別のプログラムから、APIへ直接リクエストを送れるためです。

認可はサーバー側で毎回行うことが重要です。IDが推測しにくいUUIDでも、所有者やアクセス権の検査を省略できません。OWASP: リクエストごとの権限検証

編集処理なら、検証済みの利用者IDを更新条件に含めます。次は仕組みを示すSQLの例です。

sql

UPDATE animemos
SET title = $1
WHERE id = $2
  AND user_id = $3
RETURNING id;

$3 は認証済みのセッションやJWTからサーバーが得た値です。クライアントが指定した所有者IDではありません。更新結果が0件なら、成功したことにしてはいけません。

閲覧も同様です。有料ページを購入者にだけ見せるなら、未購入者に返すレスポンスから本文と図のデータを除きます。

OAuthやOIDCを導入しても、自分のアプリの所有者チェックが自動的に完成するわけではありません。正当なトークンであっても、対象の教材を編集してよいかは別途判断します。

図の三枚のカードは、同じ関門へつながる別々の道具です。「認証方式の名前」としてひとまとめにせず、担当する仕事で整理しましょう。OAuthの役割・OIDCの概要

答えは、Bから編集権限を与えられるなどの許可条件がなければ、できません。認証に成功しても、認可が成功したことにはなりません。

実装を読むときは、リクエストの主語を確定する箇所と、対象への操作を判定する箇所を探してください。二つを別の問いとして説明できれば、この教材の要点をつかめています。

図の最後では人物カードは同じまま、許可と拒否に分岐しています。権限は「ログイン済み」という一個のスイッチではなく、主語・対象・操作に対する答えです。