授權與 API 整合

僅在所有條件滿足時允許

檢查已驗證的操作方與租戶、請求操作、記錄及授權有效性。缺少必要條件時預設拒絕。

操作方

已驗證的服務或合作方。不要信任請求正文中的 client_id。

記錄

將記錄限制在已驗證的 tenant_id 內。

操作與用途

檢查 shipping.address.read 等許可權及其關聯的配送用途。

附加條件

檢查接收方、有效期、撤銷、使用次數及與個人的關係。

一致的授權決策

考慮授權、讀取及使用次數更新之間的狀態變化。

服務身份驗證與憑據

使用 Microsoft Entra 應用程式 Bearer token。Azure 可用 Managed Identity，憑證方式以私密金鑰驗證應用程式並取得權杖，並非傳輸層 mTLS。目前 Vault 信任一個 Entra 目錄，不會自動支援其他組織。認證資料僅置於後端。

接收方限制

驗證權杖的目標接收方及目的地，拒絕為其他 API 簽發的權杖。

憑據輪換

管理舊憑據退役及過渡期。

分離瀏覽器與伺服器憑據

絕不將伺服器憑據嵌入 JavaScript 或 HTML。

錯誤、重試與審計

內部記錄拒絕原因，不洩露其他租戶記錄或個人資料。超時後結果不明時，使用冪等鍵或狀態查詢，而非盲目重試。

401 / 403

區分缺少身份驗證與缺少授權，在受保護的內部日誌中記錄詳情。

404

考慮對不存在的記錄與未獲授權的記錄回傳無法區分的響應。

409 / 429

冪等衝突與請求限流。定義重試策略及等待時間。

503

無法檢查授權或撤銷狀態時停止處理，不將請求視為已授權。

DATA / INTEGRATION EXAMPLE

資料與整合示例

這些示例用於說明設計。欄位名及值僅供演示，並非可執行的 API 參考。

{
  "operation": "Authorization inputs and decision example",
  "authenticated_context": {
    "tenant_id": "tenant_a",
    "client_id": "carrier-a"
  },
  "request": {
    "action": "shipping.address.read",
    "resource_ref": "order_example_01",
    "purpose": "fulfillment"
  },
  "decision": {
    "allowed": true,
    "fields": [
      "postal_code",
      "address",
      "recipient_name"
    ],
    "decision_id": "dec_example_01"
  }
}

從已驗證憑據構建身份上下文，絕不以客戶端提供的 tenant_id 作為許可權依據。

相關技術設計

為您的業務流程設計整合。

梳理留存資料、合作方及必要操作，尋找減少暴露的方法。