システムデザイン面接：リクエストバインド型の委任権限検証システムをどのように設計するか？

プロンプトとスコープ

個人または組織の代理として金銭の支出、従量課金リソースの消費、規制対象データの開示、または本番環境ステートの変更を行うエージェント、ワークロード、またはバッチジョブ向けの委任権限検証レイヤーを設計します。システムは保護されたリクエストを処理する前に、境界付けられた権限を証明する必要があります。プロンプトは2026年のIETF HTTPAPI Internet-Draftを参照しています。これは策定中のドラフトであり、最終的なRFCではなく、決済プロトコルでもありません。

面接官がテストしているポイント

アイデンティティ認証、委任認可、リクエストの完全性、決済の分離。
401チャレンジ、403拒否、nonce、有効期限、リクエストバインディングの設計。
リプレイ攻撃、テナント間での再利用、プロキシ、鍵ローテーション、監査性の処理。
影響の大きいアクションを実行する前の予算、ポリシー、フェイルクローズド境界の適用。

回答前に明確にすべき質問

保護対象のアクションは、データエクスポート、本番環境への書き込み、ダウンストリーム呼び出し、予算消費のどれですか？
プリンシパル、発行者、委任されたリクエスタ、検証者は誰が運用していますか？
権限はHTTPメソッド、ターゲットURI、リクエストダイジェストにバインドする必要がありますか？それともリソーススコープのみですか？
オフライン検証は許可されていますか？また、nonceの可用性とクロックスキューはどのように処理されますか？
失敗した場合、リクエストを拒否すべきですか？それとも人間の承認が必要ですか？あるいは読み取り専用にダウングレードすべきですか？

30秒の回答フレームワーク

問題を4つのレイヤーに分割します：既存のアイデンティティはリクエスタが誰であるかを証明します。委任は誰の代理として行動し、何を実行でき、どのような制限があるかを示します。リクエストバインディングは証明を1つのリクエストに制限します。ポリシーは今実行が許可されるかを決定します。許容可能な証明が存在しない場合は401チャレンジを返し、証明は理解できるものの不十分な場合は403を返します。発行者、リクエスタ、プリンシパル、有効期限、nonce、メソッド、URI、ダイジェスト、予算制限を含めます。検証後にのみ実行し、フェイルクローズドとし、すべての拒否を監査します。

ステップバイステップの詳細解説

1. ロールと信頼境界の定義

プリンシパルは個人、組織、またはサービスです。委任されたリクエスタはエージェント、デバイス、ジョブ、またはワークロードです。発行者はプリンシパルのために証明に署名し、検証者は保護されたリソースまたはゲートウェイに配置されます。証明の取得にはOAuth Token Exchangeなどの発行システムを使用できます。検証者は同意やアカウント連携ではなく、チャレンジと提示を処理します。

2. チャレンジとレスポンスの設計

許容可能な証明がない場合、401、WWW-Authenticate: Delegation、およびCache-Control: no-storeを返します。証明の構文は有効であるもののローカルポリシーを超えている場合は403を返します。Problem Detailsを使用して失敗の理由を説明できますが、説明用フィールドによってチャレンジを緩和してはなりません。

http

HTTP/1.1 401 Unauthorized
Cache-Control: no-store
WWW-Authenticate: Delegation realm="api.example",
  version=1, profile="budget", nonce="n-123", max-age=300

検証者はnonce、プロファイル、有効期限ウィンドウを制御し、証明がリクエスト間でコピーされないようにします。

3. 将来のリクエストへの証明のバインド

少なくともHTTPメソッド、信頼できるオリジン、ターゲットURI、リクエストダイジェスト、有効期限をバインドします。プロキシがHostやパスを書き換える場合、信頼できるゲートウェイ設定からのみオリジンを再構築します。検証されていないX-Forwarded-*は決して信頼してはいけません。メソッドの大文字/小文字、クエリの順序、パーセントエンコーディングの正規化を定義します。

json

{
  "principal": "org-42",
  "requester": "job-7",
  "method": "POST",
  "origin": "https://api.example",
  "target_hash": "sha-256:...",
  "nonce": "n-123",
  "expires": "2026-08-04T05:00:00Z",
  "limits": {"USD": 250}
}

4. 検証順序とフェイルクローズドな挙動の設定

バージョンとフォーマットをパースし、署名、発行者の信頼性、nonceの鮮度、時間ウィンドウ、リクエストバインディング、ローカル予算を検証します。依存関係が利用できない場合、CBORが非決定的である場合、署名が失敗した場合、またはnonceの状態が失われた場合は拒否します。アイデンティティ認証情報と委任証明は個別のレイヤーとして検証します。1つの有効な証明が無関係なAPIキーを認可してはなりません。

5. リプレイとテナント間再利用の防止

短いTTL、アトミックな消費、テナント分離を用いてnonceを保存します。リクエストダイジェストとターゲットオリジンにより、あるAPI向けの証明を別のAPIへコピーすることを防ぎます。再利用されたnonceを拒否し、クロックスキューを制限し、プリフライトと最終リクエストで同一のバインディングフィールドを使用します。リスクの高いアクションには、1回限りの証明と人間の承認を要求できます。

6. 予算とポリシーの適用

予算は権限プロファイルであり、決済や清算ではありません。ポリシーにより、金額、サービスユニット、データスコープ、環境、ダウンストリーム呼び出しを制限できます。アクションと同じトランザクション境界内でデビット処理を行うか、補償予約（compensating reservation）を使用して、並行リクエストが共同して制限を超えないようにします。

7. 鍵の運用と安全な監査

発行者はローテーション可能な鍵とバージョンを公開します。検証者はそれらをキャッシュしてもかまいませんが、失効と緊急ローテーションをサポートする必要があります。プリンシパル、リクエスタ、ターゲット、ポリシー結果、証明ID、拒否理由を監査します。完全なトークン、秘密鍵、機密データは決してログに記録してはいけません。401/403率、nonceリプレイ、検証レイテンシ、ポリシー拒否、予算超過、鍵ローテーション失敗、承認時間を追跡します。

高品質な回答例

システムをアイデンティティ、委任、リクエストバインディング、ポリシーの各レイヤーに分割します。OAuthなどの発行者がプリンシパルとの関係を証明します。委任証明にはプリンシパル、リクエスタ、プロファイル、有効期限、予算が含まれ、検証者はそれを実行されるHTTPメソッド、信頼できるオリジン、ターゲットURI、リクエストダイジェスト、nonceにバインドします。

証明がない場合はWWW-Authenticate: Delegationとno-storeを含む401を返し、有効であるものの不十分な場合は403を返します。フォーマット、署名と発行者の信頼性、nonceの鮮度、時間ウィンドウ、リクエストバインディング、テナントポリシー、予算の順に検証します。署名の失敗、依存関係の利用不可、nonceステートの喪失が発生した場合はフェイルクローズドとします。この証明は決済を定義するものではなく、HTTP Message Signaturesを置き換えるものでもなく、OAuthの発行や同意を実装するものでもありません。

アクションのトランザクションまたは補償予約内で予算をデビットし、テナント分離されたnonceをアトミックに消費します。鍵ローテーションと緊急失効をサポートし、ログには証明ID、プリンシパル、ターゲット、結果のみを保持します。リプレイ、テナント間コピー、プロキシによる書き換え、並行超過消費、鍵ローテーションをテストします。目的は、重要なアクションが発生する前に「誰が誰のために行動し、この特定のリクエストに対して何をすることが許可されているか」を証明することです。

よくある間違い

委任証明を一般的なアイデンティティ、OAuth発行、または決済プロトコルとして扱うこと。
メソッド、URI、ダイジェスト、nonce、または有効期限のバインディングなしで長寿命トークンを発行すること。
署名の依存関係が利用できない場合にリクエストを許可すること。
ターゲットに対してプロキシが書き換えた値や信頼できないX-Forwarded-*の値を信頼すること。
完全な認証情報をログに記録したり、アクションの後にデビットを行ったりして、リプレイや超過消費の隙を作ること。

フォローアップの質問と回答

なぜ401と403の両方を使用するのですか？

401は証明が存在しない、無効、または不完全であることを意味し、クライアントはチャレンジから新しい証明を取得できます。403は証明は理解されたものの、権限、予算、またはローカルポリシーが不十分であることを意味し、再試行しても解決しません。

nonceサービスが一時的に利用できない場合はどうしますか？

高リスクなリクエストに対してはフェイルクローズドとし、診断用のno-storeエラーを返します。明示的に評価された低リスクの読み取り専用アクションのみ、制限付きのフォールバックを許可できます。キャッシュされた古いnonceは1回限りのステートではありません。

これはOAuthとどのように連携しますか？

OAuth Token ExchangeまたはGNAPを使用して委任マテリアルを取得できます。検証者はリクエストにバインドされた証明を個別に検証します。委任されたスコープがアイデンティティトークンのすべての権限と混同されないよう、アイデンティティトークンと委任証明は個別に検証します。

これは決済プロトコルですか？

いいえ。予算プロファイルは金額やサービスユニットの制限を表現できますが、清算、決済レール、HTTP 402セマンティクスは外部のものです。検証者は保護されたアクションが委任ポリシーを満たしているかどうかのみを判断します。