Claude API 四種驗證方式：Anthropic、AWS、Google 與 Azure

Claude API 的四種驗證路徑

Claude API 的驗證取決於一個決定：您的客戶端要在連線上傳送哪種憑證。共有四種方案，且它們並非同一機制的變體。直接使用 Anthropic API 時，需在 x-api-key 標頭中傳送靜態金鑰。Amazon Bedrock 則使用 AWS 憑證對每個請求進行簽章，此架構中完全不涉及 Anthropic 金鑰。Google Cloud 傳送的是短效的 Google 存取權杖 (access token)。Microsoft Foundry 則採用 Azure 核發的金鑰或 Microsoft Entra 權杖。

本指南適用於將 SDK (軟體開發套件) 整合至執行於 Linux 伺服器上的服務。若您是要設定 Claude Code 命令列工具，其變數與流程有所不同：請參閱 將 Claude Code 指向 Bedrock 或 Vertex。若服務尚未建立，請先透過 在 VPS 上建立第一個 Claude API 應用程式 完成建置，再回到此處設定憑證。

以下內容皆已於 2026 年 8 月與 Anthropic 平台文件核對。由於模型識別碼、價格、SDK 版本與端點格式均會變動，本指南直接連結至各供應商頁面，而非列出可能過時的數值。

途徑 1：Anthropic API 金鑰

這是最直接的路徑，也是唯一由 Anthropic 核發密鑰的方式。請求會發送至 Anthropic API 主機上的 Messages 端點，且每個請求皆需包含三個標頭。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "MODEL_ID", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

請將 MODEL_ID 替換為 Anthropic 模型概覽 中的當前識別碼。正常的響應為包含 content 陣列與 usage 物件的 JSON。金鑰錯誤或過期會回傳 HTTP 401 與 authentication_error。若缺少 anthropic-version 標頭則會導致另一種錯誤，因為該標頭在每個請求中皆為必要；SDK 會自動為您設定。

客戶端建構是四種途徑中最簡短的，因為無需進行任何建構。所有官方 SDK 都會自動從環境變數中讀取 ANTHROPIC_API_KEY。

import os
from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment

message = client.messages.create(
    model=os.environ["CLAUDE_MODEL"],
    max_tokens=64,
    messages=[{"role": "user", "content": "Hello"}],
)
print(message.usage)

建議將模型識別碼與金鑰一併存放在環境變數中。模型名稱會依排程變更，且該排程非您所能控制；透過重新部署程式碼來修改單一字串是可避免的作業。

金鑰是在 Console 中建立的，建立時需選擇過期時間：預設選項為 3 小時、1 天、7 天或 30 天，亦可自訂時長或選擇「永不過期」。過期時間在建立時即固定，事後無法更改。 Anthropic 會在長期金鑰過期前通知建立者，但短期金鑰過期時不會發送任何警告郵件。過期金鑰會回傳 401 且無法重新啟用，因此解決方法永遠是建立新的金鑰。

直接使用 API 時無需選擇區域，費用會直接計入您的 Anthropic 組織。工作區（Workspaces）可將金鑰限制在單一專案內，這是追蹤單一服務支出最清晰的方式。關於帳單計算方式，請參閱 API 按 Token 計費與訂閱制的比較。

此處還有一項選擇，因為它完全移除了靜態密鑰。工作負載身分聯合（Workload Identity Federation）允許工作負載將來自您既有信任身分提供者的 OpenID Connect (OIDC) 權杖，交換為 POST /v1/oauth/token 的短期 Anthropic 權杖，SDK 會在權杖過期前自動更新。過程中不會產生或複製任何 sk-ant-api... 字串。此機制適用於已具備平台身分的 Kubernetes、GitHub Actions 與雲端虛擬機。一般的 VPS 通常沒有此類發行者，因此在該環境下，將 API 金鑰存於檔案中是務實的做法，本指南後續內容亦以此為準。

途徑 2：使用 Amazon Bedrock 的 AWS 憑證

在 Bedrock 上，您完全不需要持有 Anthropic 金鑰。SDK 會使用一般的 AWS 憑證，透過 AWS Signature Version 4 (SigV4) 對每個 HTTP 請求進行簽章，由 AWS 決定該呼叫者是否具備模型調用權限。

pip install -U "anthropic[bedrock]"
aws sts get-caller-identity

aws sts get-caller-identity 會印出您的憑證所對應的帳號號碼與 ARN (Amazon Resource Name)。請務必在執行任何操作前先執行此指令。若此指令失敗，Claude 的呼叫也會失敗，因為 SDK 遵循相同的解析鏈：優先使用建構子參數，接著是 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKEN 與 AWS_REGION 環境變數，最後才是 AWS 設定檔與其餘標準鏈（SSO、擔任角色、ECS 任務角色、執行個體中繼資料服務）。

在客戶端建構時，變更的部分僅在於類別與一個參數。

from anthropic import AnthropicBedrock

client = AnthropicBedrock(aws_region="us-east-1")

在此處，區域 (Region) 不再只是裝飾。Bedrock 端點是依區域劃分的，模型存取權限需在 AWS 主控台中按區域授予，且區域是 SigV4 簽章的一部分，因此在某個區域計算出的簽章無法用於另一個區域。請在服務環境中明確設定 AWS_REGION。Anthropic 文件指出 AnthropicBedrock 客戶端會讀取 AWS_REGION，若未設定則回退至 us-east-1，且該客戶端不會讀取 ~/.aws/config 來獲取區域資訊。這就是為什麼 AWS CLI 可以在您的 Python 程序失敗的同一台機器上成功列出 Claude 模型：因為 CLI 讀取了您的設定檔，而客戶端卻沒有。

在 EC2 執行個體上，您可以附加 IAM (Identity and Access Management) 角色，這樣就不會有任何祕密存放在磁碟上，因為執行個體中繼資料服務會將臨時憑證提供給 SDK。AWS 之外的 VPS 既沒有執行個體角色，也沒有中繼資料服務。此時您必須在兩者間做出選擇：一是將 IAM 使用者的長期存取金鑰對存放在機器上（這與 Anthropic 金鑰屬於同類型的祕密），二是使用聯合身分：向您的身分提供者進行驗證，呼叫 AWS STS (Security Token Service)，並使用其回傳的臨時憑證。Bedrock 也接受透過 AWS_BEARER_TOKEN_BEDROCK 傳遞的持有人權杖 (bearer token)，文件記載其有效期限上限為 12 小時，且被 AWS 描述為最不建議使用的途徑。

費用會直接計入您的 AWS 帳號而非 Anthropic，這通常是選擇此途徑的主要原因。根據 2026 年 8 月的文件記載，區域端點的費用比全域端點高出 10%。有一種 Bedrock 錯誤值得注意，因為它看起來像權限問題，但其實不然：Invocation of model ID ... with on-demand throughput isn't supported. Retry your request with the ID or ARN of an inference profile that contains this model. 這是模型路由問題，任何憑證變更都無法解決。

路由 3：Vertex AI 上的 Google 憑證

Google Cloud 使用應用程式預設憑證 (Application Default Credentials, ADC)，這是 Google 驗證程式庫在未指定憑證時，依循的一套固定搜尋順序。ADC 會先檢查 GOOGLE_APPLICATION_CREDENTIALS，接著是 gcloud auth application-default login 寫入的檔案，最後是透過中繼資料伺服器 (metadata server) 附加的服務帳號。

pip install -U "anthropic[vertex]"
gcloud auth application-default login

在工作站上，登入動作會寫入 $HOME/.config/gcloud/application_default_credentials.json，這樣就完成了。但在伺服器上，這並非正確工具，因為它儲存的憑證屬於個人，且會隨該人員的帳號失效而失效。在 Google Cloud 外部也沒有中繼資料伺服器，因此 ADC 會退而求其次，改用指向服務帳號金鑰檔案的 GOOGLE_APPLICATION_CREDENTIALS。該 JSON 檔案屬於長效機密，必須嚴格遵守本指南後續說明的處理方式。若在 Google Cloud 內部，只需將服務帳號附加至 VM，便無需保護任何檔案。

from anthropic import AnthropicVertex

client = AnthropicVertex(project_id="my-project", region="global")

若跳過 SDK 直接使用原始 HTTP，會有兩處變更。模型識別碼會從請求主體 (request body) 移至 URL 路徑，而 anthropic_version 則會從標頭 (header) 移至主體，且必須讀取為 vertex-2023-10-16。該憑證為一般的 Google 存取權杖 (access token)。

curl https://aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/publishers/anthropic/models/${MODEL_ID}:rawPredict \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -d '{"anthropic_version": "vertex-2023-10-16", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

區域 (Region) 是首要參數。global 會為了可用性進行動態路由，us 與 eu 為多區域識別碼，而如 us-east5 的名稱則會鎖定單一區域。根據 2026 年 8 月的文件記載，多區域與區域端點的費用比全域端點高出 10%。計費透過 Google Cloud 專案執行，因此配額與發票皆由 Google 管理。

路由 4：Microsoft Foundry 是 Azure 的路由

若您搜尋的是 Azure 上的 Claude，這正是您需要的章節，且目前已有支援的路由。Claude 運行於 Microsoft Foundry（前身為 Azure AI Foundry），並透過 Azure Marketplace 以 Claude Consumption Units 計費。您需建立一個 Foundry 資源，在其中部署 Claude 模型，並呼叫位於 https://{resource}.services.ai.azure.com/anthropic/v1/* 的 Azure 託管端點。

有兩種憑證可供使用。第一種是從 Foundry 入口網站中部署項目的「詳細資料」頁籤所取得的 Azure 發行金鑰，需透過 api-key 或 x-api-key 標頭傳送。第二種是 Microsoft Entra 權杖，這是伺服器端的較佳選擇，因為 Azure 的角色型存取控制（RBAC）可藉此管理誰能呼叫該端點。

ACCESS_TOKEN=$(az account get-access-token --resource https://ai.azure.com --query accessToken -o tsv)

curl https://${RESOURCE}.services.ai.azure.com/anthropic/v1/messages \
  -H "content-type: application/json" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model": "DEPLOYMENT_NAME", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

model 欄位填寫的是您的部署名稱，而非模型識別碼。預設情況下兩者相同，但一旦您自行命名部署，兩者便會不一致，這通常是導致請求正確卻出現 Deployment not found 錯誤的原因。Python 與 TypeScript SDK 會從環境變數中讀取 ANTHROPIC_FOUNDRY_API_KEY 與 ANTHROPIC_FOUNDRY_RESOURCE。並非所有 SDK 都支援 Foundry：根據 2026 年 8 月的文件，支援範圍涵蓋 C#、Java、PHP、Python 與 TypeScript，而 Go 與 Ruby SDK 則需將通用客戶端指向 Foundry 的基礎 URL。

此替代方案有其風險。若環境中仍設定了 ANTHROPIC_API_KEY，通用客戶端會自動讀取該變數，並將您的 Anthropic 金鑰傳送至 Microsoft 端點。請務必取消設定該變數，或在客戶端停用環境預設值。Entra 權杖約一小時後會過期，因此長時間執行的處理程序必須在執行期間更新權杖，而非僅在啟動時擷取一次。

伺服器上的憑證有效期限為何？

[
  {
    "label": "Anthropic key, 30-day preset",
    "max_lifetime_hours": 720
  },
  {
    "label": "Anthropic key, 7-day preset",
    "max_lifetime_hours": 168
  },
  {
    "label": "AWS STS assumed role",
    "max_lifetime_hours": 12
  },
  {
    "label": "Bedrock bearer token",
    "max_lifetime_hours": 12
  },
  {
    "label": "Entra ID access token",
    "max_lifetime_hours": 1
  },
  {
    "label": "Federated Anthropic token",
    "max_lifetime_hours": 1
  }
]

以下為各供應商發布的上限與預設值，資料讀取時間為 2026 年 8 月，並非實際測量數值。這些數據的重要性在於：若憑證外洩，在您發現之前，這些數據代表了該憑證仍能運作的時間長度。圖表下方的短效期 Token 每個僅維持 1 小時，且 SDK 會自動更新，因此短效期不會增加維運成本。Assumed role 的效期為 12 小時。使用 30 天預設值建立的 Key 有效期為 720 小時，這正是存放在您伺服器檔案中長達一個月的憑證。

憑證在 VPS 上的存放位置

將機密資訊存放在僅 root 可讀取的檔案中，並透過 systemd 將其傳遞給處理程序。此作法不受任何 SDK 版本更迭影響，因此值得一次性正確設定。

sudo useradd --system --home /opt/claude-app --shell /usr/sbin/nologin claudeapp
sudo install -d -m 700 -o root -g root /etc/claude-app
sudo install -m 600 -o root -g root /dev/null /etc/claude-app/env
sudoedit /etc/claude-app/env

該檔案包含純文字的 KEY=value 行。請勿使用 export、引號或 shell 語法，因為 systemd 是自行解析檔案，而非透過 shell 執行。

ANTHROPIC_API_KEY=sk-ant-api03-REPLACE-ME
CLAUDE_MODEL=REPLACE-ME

[Unit]
Description=Claude API service
After=network-online.target

[Service]
User=claudeapp
EnvironmentFile=/etc/claude-app/env
ExecStart=/opt/claude-app/venv/bin/python -m claude_app
Restart=on-failure

[Install]
WantedBy=multi-user.target

systemd 會以 root 身分讀取 EnvironmentFile=，隨後才切換至 User=claudeapp，因此服務帳號無須具備該檔案的讀取權限。將檔案權限設為 600 並由 root 擁有即可，這也是為何上述 install 指令要如此設定的原因。使用 sudo systemctl enable --now claude-app 啟動服務，接著透過 systemctl status claude-app 確認單元（unit）已進入 active (running) 狀態，而非陷入重啟迴圈。

請避免以下四種行為，每項都有您可以自行驗證的原因：

• 請勿將金鑰直接寫入單元檔案中的 Environment=。位於 /etc/systemd/system 下的單元檔案可供所有使用者讀取，因此 systemctl cat claude-app 會將機密資訊顯示給任何本機使用者。
• 請勿將其提交至版本控制。.gitignore 僅能防止新檔案被提交，對於已提交的檔案無效，因為 git 歷史紀錄會保留所有曾被寫入的內容。
• 請勿將其寫入容器映像檔。ENV 行與 --build-arg 值會被記錄在映像檔層中，而 docker history --no-trunc 會將其顯示出來。在後續層中刪除該檔案，並無法將其從先前的層中移除。請改用 --env-file 或掛載檔案的方式在執行時期傳遞機密資訊。
• 請勿認為處理程序環境對 root 而言是私密的。sudo tr '\\0' '\\n' < /proc/$(pgrep -u claudeapp -f claude_app | head -1)/environ 會將金鑰顯示出來。此設計的目標是防止機密資訊被伺服器上其他帳號取得，而非防止 root 存取，因為 root 無論如何都能讀取這些資訊。

最後一點界定了此設計的防護範圍。當只有服務本身與 root 能讀取機密時，環境變數是存放機密的合適容器。但若處理程序會執行非您編寫的程式碼，則環境變數並非合適的存放處，因為處理程序能執行的任何程式碼都能讀取其自身的環境。防止 AI 代理存取機密 探討了該情況，這屬於不同的問題，也有不同的解決方案。

如何不中斷服務進行金鑰輪替？

採取向前輪替，最後再撤銷舊金鑰。

1. 在 Console 中，於舊金鑰所在的相同工作區建立新金鑰。
2. 使用 sudoedit 將其寫入 /etc/claude-app/env。
3. 執行 sudo systemctl restart claude-app。
4. 確認服務能正常回應請求後，再於 Console 中撤銷舊金鑰。

EnvironmentFile 會在單元啟動時讀取，因此執行中的處理程序會保留啟動時取得的數值。systemctl daemon-reload 會重新讀取單元檔案，但不會更動執行中處理程序的環境變數，因此必須重新啟動才能套用新金鑰。若在步驟 1 而非步驟 4 撤銷金鑰，將導致服務中斷，直到步驟 3 完成為止。

另外三種路徑是在供應商端進行輪替。IAM 使用者支援同時啟用兩組存取金鑰，因此請建立第二組、部署完成後，再刪除第一組。Google 服務帳戶金鑰的輪替方式相同。Foundry 金鑰是在入口網站重新產生，這會立即導致舊金鑰失效，因此請務必在點擊前先寫入新數值。Entra 權杖與聯合 Anthropic 權杖完全無需輪替，這也是在適用情境下優先選用它們的最強理由。

在操作 Console 時，請順便為工作區設定支出上限。金鑰外洩最直接的後果就是產生高額費用，限制 VPS 上代理程式的支出上限 一文詳細說明了相關控制項的操作方式。

為什麼我的客戶端會收到 401 或 403 錯誤？

直接呼叫 API 時收到 401 且顯示 authentication_error。 金鑰錯誤、已撤銷或已過期。過期是最常被忽略的原因，因為程式碼未更動且昨日請求仍正常運作。請檢查 Console 中金鑰的過期欄位，或透過 Admin API 讀取 expires_at；若金鑰無過期限制，該值會顯示為 null。

SDK 忽略了您的聯合身分設定並改用金鑰。 ANTHROPIC_API_KEY 與 ANTHROPIC_AUTH_TOKEN 在憑證優先順序中高於聯合身分，因此兩者皆會覆蓋該設定。常見的陷阱是：匯出的變數若為空字串仍會佔用位置，因此 ANTHROPIC_API_KEY="" 會導致 SDK 使用空金鑰進行驗證，而非向下尋找。請改用 unset ANTHROPIC_API_KEY。

聯合身分驗證時收到 401 且訊息僅顯示 Authentication failed。 此訊息刻意針對所有失敗原因統一顯示，以防止呼叫者透過錯誤文字探測您的規則配置。實際原因記錄在 Console 的驗證歷史頁面中。請從該處著手，而非盲目推測 JWT 的內容。

Foundry 收到 403。 權杖驗證成功，但您的 Azure 帳號缺乏執行該呼叫所需的角色。請為發出請求的身分指派 Azure RBAC 角色，例如 Foundry User（前身為 Azure AI User）或 Cognitive Services User。

Bedrock 相關問題。 請先以服務使用者身分執行 aws sts get-caller-identity。此指令可確認伺服器是否具備可用的 AWS 憑證，藉此區分是憑證問題、模型存取權限問題，還是區域不符。模型存取權限是依區域在 AWS console 中授予的，很容易發生在一個區域啟用權限卻呼叫另一個區域的情況。

FAQ

在 Bedrock 或 Vertex 上使用 Claude 需要 Anthropic API key 嗎？

不需要。在 Amazon Bedrock 上，SDK 會使用 AWS 憑證並透過 SigV4 簽署每個請求；在 Google Cloud 上，則會使用透過 Application Default Credentials 取得的 Google 存取權杖。這兩種設定中都不存在 Anthropic 核發的密鑰，且使用費用會計入雲端帳戶而非 Anthropic。這也是為什麼將 Anthropic key 留在 ANTHROPIC_API_KEY 對這些主機而言是一種風險：指向雲端端點的通用客戶端會直接將其傳送過去。

Claude 是否可在 Azure 上使用？

是的，可透過 Microsoft Foundry（前身為 Azure AI Foundry）使用。您需建立一個 Foundry 資源，將 Claude 模型部署至其中，並使用 Azure 核發的 key（置於 api-key 標頭中）或 Microsoft Entra bearer token 來呼叫 https://{resource}.services.ai.azure.com/anthropic/v1/messages。使用費用會透過 Azure Marketplace 以 Claude Consumption Units 計算。請求主體中的 model 欄位必須填入您的部署名稱；除非您重新命名部署，否則該名稱與模型識別碼相同。

我應該將 Claude API key 儲存在 Linux 伺服器的什麼位置？

應儲存在由 root 擁有且權限為 600 的檔案中，並透過 systemd 單元中的 EnvironmentFile= 載入。systemd 會在切換至單元的 User= 之前以 root 身分讀取該檔案，因此服務帳號無需存取權限。請勿將其放入儲存庫、單元檔案本身（該檔案可被全域讀取，且可透過 systemctl cat 列印出來），或容器映像檔層中，因為 docker history --no-trunc 會印出任何透過 ENV 或 --build-arg 設定的內容。

為什麼我的 Claude API 請求在沒有任何變更的情況下開始回傳 401？

最常見的原因是金鑰已達到建立時設定的過期時間。過期時間是在建立時設定的，事後無法編輯，且短效金鑰過期時不會發送警告郵件。過期的金鑰無法重新啟用，因此請建立一個新的金鑰，將其寫入環境檔案，重新啟動服務，最後再撤銷舊金鑰。如果確認金鑰仍在有效期內，請檢查是否有過期的憑證覆蓋了它：設定為空字串的 ANTHROPIC_API_KEY 優先權高於所有其他憑證來源。