リソースベース認可では認可より先にリソース解決が必要
「ログインしているか」「管理者ロールを持つか」のような認可は、対象オブジェクトを読まなくても判定できる。しかし「この投稿の所有者か」「このプロジェクトのメンバーか」「このテナントのデータか」は、まず URL や引数から対象リソースを解決しないと判定できない。
この順序はリソースベース認可の基本的な制約になる。
- ルートの
{id}などから対象を特定する - DB 等からリソースを取得する
user × action × resourceで認可する- 認可済みのリソースを使って処理する
ASP.NET Core の公式ドキュメントもこの点を明示している。属性ベースの認可はデータバインディングやアクション実行より前に評価されるため、リソースをロードしてから判定する必要があるケースでは [Authorize] だけでは足りず、IAuthorizationService.AuthorizeAsync(user, resource, ...) を使う命令型の認可が必要になる。
ここで設計上の分岐が生まれる。リソース解決と認可をハンドラ自身に書くのか、Route Model Binding はリソース解決を認可から分離する のように解決だけフレームワークへ寄せるのか、さらに 認可済みリソースをハンドラ入力にすると前提を構造化できる のように「認可済みであること」までハンドラの入力条件にするのか、という違いである。
この観点で見ると、認可は単なる middleware の前処理ではない。認可対象となるリソースをいつ、どの層で具体化するかが API 設計そのものになる。