Workload Identity Federation (WIF) is the second of the Claude API's two authentication methods, alongside static API keys. The idea: your workload already has a cryptographically verifiable identity from the platform it runs on — a Google Cloud service account, an AWS IAM role, a Kubernetes service account, a GitHub Actions job. WIF lets it exchange that platform-issued identity token directly for a short-lived Claude API access token. Both methods grant the same access to Claude API endpoints; the difference is that with WIF there is no long-lived secret anywhere in your system.
How the exchange works
The workload presents its identity provider's JWT (a signed identity document) to the Claude API's token endpoint — POST /v1/oauth/token, using the standards-based RFC 7523 jwt-bearer grant — and receives back a short-lived sk-ant-oat01-... access token, sent on subsequent requests as Authorization: Bearer. You almost never do this by hand: the official SDKs perform the exchange and refresh the token automatically before it expires. Token lifetime is configurable on the federation rule between 60 and 86,400 seconds, with a default of one hour.
WIF works with AWS IAM, Google Cloud, or any standards-compliant OIDC issuer — the documentation explicitly lists GitHub Actions, Kubernetes service accounts, SPIFFE, Microsoft Entra ID, and Okta. That covers keyless auth from GCP, from Azure workloads via Entra ID, and from CI systems, all through the same mechanism.
Setting it up
Configuration lives in the Claude Console and involves three resources: a service account (the identity your workload acts as), a federation issuer (which IdP's tokens to trust), and a federation rule (binding the two, plus token lifetime and scopes). The SDK is then pointed at the rule via environment variables:
# Environment for the workload — no secret among them
export ANTHROPIC_FEDERATION_RULE_ID="..."
export ANTHROPIC_ORGANIZATION_ID="..."
export ANTHROPIC_SERVICE_ACCOUNT_ID="..."
# The platform-issued JWT, direct or via file:
export ANTHROPIC_IDENTITY_TOKEN_FILE="/var/run/secrets/token"With those set, plain Anthropic() in Python works with no key. Two refinements: if the federation rule is enabled for more than one workspace, set ANTHROPIC_WORKSPACE_ID to pin the minted token to one (switching workspaces requires a new exchange). And rules carry OAuth scopes — workspace:developer, workspace:inference, workspace:manage_tunnels, org:admin — so a token scoped for inference gets HTTP 403 on anything else, a clean least-privilege boundary.
ANTHROPIC_API_KEY or ANTHROPIC_AUTH_TOKEN in the environment shadows federation entirely — even set to an empty string. If WIF "isn't working," check for a leftover key variable first and unset it rather than blanking it.Where Anthropic recommends it
The official guidance is direct: WIF for production workloads on cloud platforms, CI/CD, and Kubernetes; API keys for local development, prototyping, scripts, and single-tenant servers. The reasoning is operational. Keys have no expiry, so their safety depends on your storage and rotation discipline; WIF tokens expire on their own schedule and are minted fresh from an identity your cloud already attests. There is nothing to rotate and nothing to leak from a config file.
Equivalent patterns on the 3P platforms
WIF as described above authenticates you to the first-party Claude API. The third-party platforms achieve the same "no stored secret" property with their own native mechanisms, and the effect is equivalent:
| Surface | Keyless pattern |
|---|---|
| Claude API (1P) | WIF token exchange, any OIDC issuer |
| Claude Platform on AWS | SigV4 via the AWS credential provider chain — IAM roles, IRSA, web identity for GitHub Actions |
| Amazon Bedrock | Standard AWS credentials (IAM roles) |
| Google Vertex AI | Application Default Credentials (attached service accounts) |
On Claude Platform on AWS specifically, the AnthropicAWS client signs requests with whatever the AWS default provider chain supplies — environment credentials, SSO, web identity token files (Kubernetes IRSA, GitHub Actions), ECS container credentials, or EC2 instance metadata — so a role-based deployment is keyless out of the box. See the platform's SDK setup guide for details.
Where to go next
Compare with API key authentication for the cases where a static key is genuinely fine, and see the full env var list for exactly where the federation variables sit in the SDK's credential precedence order.