Webアプリのリソース認可パターン 調査ノート

Web アプリケーションで「URL から対象リソースを取得し、そのリソースに対する権限を判定し、認可済みの状態を下流へ渡す」設計を、責務ごとに分けて整理するためのハブ。

基本制約

• リソースベース認可では認可より先にリソース解決が必要 — 所有者判定などでは、認可より先に対象リソースを解決する必要がある

リソース解決をフレームワークへ寄せる

• Route Model Binding はリソース解決を認可から分離する — Laravel / Symfony の Route Model Binding・EntityValueResolver は「取得」を認可から分離する

認可済み状態を入力として表す

• 認可済みリソースをハンドラ入力にすると前提を構造化できる — tanukirpc / FastAPI のように、認可成功後の値をハンドラ入力にする
• パス階層を認可階層として使う — URL 階層と権限境界が一致するなら、ルート木を認可木として使える
• request-scoped DI をセキュリティコンテキストとして使う — request-scoped DI / Registry を認証済み user・tenant・resource の運搬路にする

認可を別の層に置く

• 認可をルーティングではなくメソッド境界に置く — Spring Security や ASP.NET Core のように、リソースや業務操作が具体化した method boundary で認可する

フレームワークの外にある先行研究

• 認可をプログラム構造で表す研究 調査ノート — object-capability、proof-carrying authorization、dependent/refinement type、AURA/PCML₅、Zanzibar/OpenFGA、Cedar、Macaroons/Biscuit を比較する別ハブ
• 「認可済みリソース型」は既存研究の直訳ではなく設計上の合成 — Authorized<Resource> を既存研究の直訳とは扱わず、普通の型システム上での engineering synthesis として整理
• 認可済み値には lifetime と再検証の問題が残る — request-local evidence にも revocation / freshness / atomicity の問題が残る

tanukirpc との接続

• tanukirpc の RouteWithTransformer — RouteWithTransformer 自体の API・型パラメータ上の性質

全体を通して見ると、フレームワーク間の違いは「認可機能があるか」よりも、path -> resource -> authorization -> handler/service のどの境界をフレームワークが抽象化し、認可済みという事実をどの形で次段へ伝えるかにある。

ただし、認可済み resource を DI へ入れることと object-capability security は同義ではない。変換後 scope に unrestricted DB/repository が残るなら、authority はその resource に閉じていない。この点は 認可をプログラム構造で表す研究 調査ノート 側で、文献上の capability / proof / type / relationship model を区別している。