共用方式為


驗證、要求和回應

Azure Key Vault 提供兩種類型的容器來儲存和管理雲端應用程式的秘密:

容器類型 支援的物件類型 數據平面端點
保存庫
  • 受軟體保護的金鑰
  • 受 HSM 保護的金鑰 (含進階 SKU)
  • 證書
  • 儲存體帳戶金鑰
https://{vault-name}.vault.azure.net
受控 HSM
  • 受 HSM 保護的金鑰
https://{hsm-name}.managedhsm.azure.net

以下是用來存取每種物件類型的URL後綴

物件類型 URL 尾碼
受軟體保護的金鑰 /keys
受 HSM 保護的金鑰 /keys
秘密 /secrets
證書 /憑證
儲存體帳戶金鑰 /storageaccounts

Azure Key Vault 支援 JSON 格式化的要求和回應。 搭配使用 HTTPS 與一些 URL 參數以及 JSON 編碼要求和回應本文,以將對 Azure Key Vault 的要求導向至有效的 Azure Key Vault URL。

本文涵蓋 Azure Key Vault 服務的特定內容。 如需使用 Azure REST 介面的一般資訊,包括驗證/授權以及如何取得存取令牌,請參閱 Azure REST API 參考

要求 URL 結構

密鑰管理作業使用 HTTP 動詞命令,包括 DELETE、GET、PATCH 和 PUT。 現有金鑰物件的密碼編譯作業會使用 HTTP POST。

對於不支援特定 HTTP 動詞命令的用戶端,Azure Key Vault 允許搭配 X-HTTP-REQUEST 標頭使用 HTTP POST 來指定預期的動詞。 使用 POST 做為替代項目 (例如,取代 DELETE) 時,針對通常不需要 POST 的要求,包含空白本文。

若要在 Azure Key Vault 中使用物件,以下是範例 URL:

  • 若要在 Key Vault 中 CREATE (建立) 稱為 TESTKEY 的金鑰,請使用 - PUT /keys/TESTKEY?api-version=<api_version> HTTP/1.1

  • 若要將名為 IMPORTEDKEY 的金鑰匯入 Key Vault 使用 - POST /keys/IMPORTEDKEY/import?api-version=<api_version> HTTP/1.1

  • 若要在 Key Vault 中取得名為 MYSECRET 的秘密,請使用 - GET /secrets/MYSECRET?api-version=<api_version> HTTP/1.1

  • 若在 Key Vault 中使用名為 TESTKEY 的金鑰簽署摘要, 請使用 - POST /keys/TESTKEY/sign?api-version=<api_version> HTTP/1.1

  • 對 Key Vault 提出要求的授權單位一律如下,

    • 保存庫:https://{keyvault-name}.vault.azure.net/
    • 針對受控 HSM: https://{HSM-name}.managedhsm.azure.net/ 金鑰一律儲存在 /keys 路徑下,而秘密一律儲存在 /secrets 路徑下。

支援的 API 版本

Azure Key Vault 服務支援通訊協定版本控制,以提供與下層用戶端的相容性,但並非所有功能都可供這些用戶端使用。 客戶端必須使用 api-version 查詢字串參數來指定其支援的通訊協定版本,因為沒有預設值。

Azure Key Vault 通訊協定版本遵循使用 {YYYY}.{MM}.{DD} 格式的日期編號方式。

要求本文需求

根據 HTTP 規格,GET 作業不得有要求內容,而 POST 和 PUT 作業則必須具有要求內容。 DELETE 作業中的主體在 HTTP 中是選擇性的。

除非在作業描述中另有說明,否則要求本文內容類型必須是 application/json,且必須包含符合內容類型的串行化 JSON 物件。

除非在作業描述中另有說明,否則 Accept 要求標頭必須包含 application/json 媒體類型。

回應本文格式

除非在作業描述中另有說明,否則成功和失敗作業的回應本文內容類型都是 application/json,並包含詳細的錯誤資訊。

使用 HTTP POST 做為替代方案

某些用戶端可能無法使用特定 HTTP 動詞,例如 PATCH 或 DELETE。 若用戶端也包含 "X-HTTP-METHOD" 標頭來指定原始 HTTP 指令動詞,則 Azure Key Vault 支援 HTTP POST 做為這些用戶端的替代方法。 本檔所定義之每個 API 都支援 HTTP POST。

處理錯誤回應

錯誤處理會使用 HTTP 狀態代碼。 一般結果如下:

  • 2xx – 成功:用於一般作業。 回應本文包含預期的結果

  • 3xx – 重新導向:可能會傳回 304「未修改」,以滿足條件式 GET。 未來可能會使用其他 3xx 代碼來指出 DNS 和路徑變更。

  • 4xx – 用戶端錯誤:用於不正確的要求、遺漏密鑰、語法錯誤、無效的參數、驗證錯誤等。回應本文包含詳細的錯誤說明。

  • 5xx – 伺服器錯誤:用於內部伺服器錯誤。 回應本文會包含摘要錯誤資訊。

    系統的設計目的是在 Proxy 或防火牆後方運作。 因此,用戶端可能會收到其他錯誤碼。

    發生問題時,Azure Key Vault 也會傳回回應本文中的錯誤資訊。 回應本文已格式化為 JSON,並採用下列格式:


{  
  "error":  
  {  
    "code": "BadArgument",  
    "message":  

      "’Foo’ is not a valid argument for ‘type’."  
    }  
  }  
}  

驗證需求

對 Azure Key Vault 的所有要求都必須經過驗證。 Azure Key Vault 支援使用 OAuth2 [RFC6749] 取得的 Microsoft Entra 存取令牌。

如需註冊應用程式並使用 Azure Key Vault 進行驗證的詳細資訊,請參閱 使用 Microsoft Entra ID 註冊用戶端應用程式

存取權杖必須使用 HTTP 授權標頭傳送至服務:

PUT /keys/MYKEY?api-version=<api_version>  HTTP/1.1  
Authorization: Bearer <access_token>  

未提供存取令牌,或當服務不接受令牌時,HTTP 401 錯誤會傳回給用戶端,並包含 WWW-Authenticate 標頭,例如:

401 Not Authorized  
WWW-Authenticate: Bearer authorization="…", resource="…"  

WWW-Authenticate 標頭上的參數如下:

  • authorization:OAuth2 授權服務的位址,可用來取得要求的存取令牌。

  • resource:要用於授權要求的資源名稱(https://vault.azure.net)。

備註

Key Vault SDK 用戶端第一次呼叫 Key Vault 以取得祕密、憑證和金鑰時,並不會提供存取權杖來擷取租用戶資訊。 其應該會在使用 Key Vault SDK 用戶端時收到 HTTP 401,其中 Key Vault 會向應用程式顯示 WWW-Authenticate 標頭,並包含需要前往並要求權杖的資源和租用戶。 如果一切都設定正確,從應用程式向 Key Vault 發出的第二次呼叫就會包含有效的權杖,並且將會成功。