[Feature]: Support Anthropic Workload Identity Federation (OIDC JWT-bearer token exchange)

[6matt]

Check for existing issues

• I have searched the existing issues and checked that my issue is not a duplicate.

The Feature

Add support for Anthropic Workload Identity Federation as an authentication method for the Anthropic provider, alongside the existing static ANTHROPIC_API_KEY flow.

Anthropic recently shipped WIF for the Claude API. Instead of a long-lived sk-ant-... key, workloads present an OIDC JWT (from AWS IAM, GCP, Azure, GitHub Actions, Kubernetes, SPIFFE, Okta, etc.) and exchange it for a short-lived sk-ant-oat01-... access token. The official Anthropic SDKs (Python, TypeScript, Go, Java, C#, PHP, Ruby) already support this.

Concretely, LiteLLM would need to:

1. Token exchange. Implement the RFC 7523 urn:ietf:params:oauth:grant-type:jwt-bearer exchange against POST https://api.anthropic.com/v1/oauth/token, sending:
   • assertion — JWT read from ANTHROPIC_IDENTITY_TOKEN_FILE (re-read on each exchange to pick up rotated projected tokens)
   • federation_rule_id (fdrl_...)
   • organization_id
   • service_account_id (svac_...)
   • workspace_id (wrkspc_...)
2. Token caching + refresh. Cache the minted access token and refresh on the same two-tier schedule the official SDKs use: advisory refresh at exp − 120s, mandatory at exp − 30s.
3. Wire into the Anthropic provider so callers can omit api_key and the minted token is sent as Authorization: Bearer ... on /v1/messages, etc. (Analogous to how feat: add ability to auth to azure with token #27556 added Azure AD token auth.)
4. Proxy config. Allow declaring federation credentials in the model config (env-var driven via ANTHROPIC_FEDERATION_RULE_ID, ANTHROPIC_ORGANIZATION_ID, ANTHROPIC_SERVICE_ACCOUNT_ID, ANTHROPIC_WORKSPACE_ID, ANTHROPIC_IDENTITY_TOKEN_FILE, mirroring the official SDKs' "zero-arg client" pattern).

Motivation, pitch

This is a security posture improvement that matters to any enterprise running LiteLLM in production. Static sk-ant-... API keys are long-lived bearer credentials: once minted, they sit in CI secret stores, container env, and shell history indefinitely, and a leak isn't detectable until someone notices the spend. Workload Identity Federation replaces them with short-lived OIDC-derived tokens that expire in minutes and are bound to a specific workload identity in the customer's own IdP — the same model that AWS STS, GCP WIF, and Azure Managed Identity already provide for those clouds' APIs.

For organizations with compliance requirements (SOC 2, ISO 27001, FedRAMP, internal "no static secrets" mandates), this is increasingly table stakes. LiteLLM already supports the equivalent flows for two of the three major clouds:

• Vertex AI WIF (feat: add workload identity federation between GCP and AWS #10210, Google WIF documentation #19320, feat(vertex_ai): support explicit AWS credentials for WIF auth #21472, fix(vertex_ai): support pluggable (executable) credential_source for WIF auth #24700)
• Azure AD token auth (feat: add ability to auth to azure with token #27556)

…but the direct Anthropic provider still requires a static sk-ant-... key, forcing customers to keep long-lived Anthropic credentials in their secret managers even when every other LLM provider in their LiteLLM config has been migrated to federated auth. This is exactly the gap Anthropic's new WIF feature was built to close, and parity with the official Anthropic SDKs (which all support it natively) means anyone migrating from the Anthropic SDK to LiteLLM doesn't have to regress on credential hygiene.

Benefits, summarized:

• Eliminates long-lived Anthropic credentials from customer environments — the largest static-secret surface for any Anthropic-using LiteLLM deployment
• Short-lived tokens (minutes, not "never") — bounded blast radius on leak; aligns with zero-standing-privilege models
• Drop-in for any OIDC IdP customers already operate (AWS IRSA, GCP metadata server, Azure IMDS, GitHub Actions, Kubernetes projected SAs, SPIFFE, Okta) — no new infrastructure required
• Parity with the official Anthropic SDKs, so this is not a non-goal for Anthropic-direct usage
• Parity with LiteLLM's existing Vertex AI WIF and Azure AD token paths, completing the "no static cloud secrets" story across all three major providers

Docs: https://platform.claude.com/docs/en/manage-claude/workload-identity-federation
Reference (env vars, profile schema, error codes): https://platform.claude.com/docs/en/manage-claude/wif-reference

I searched the repo and didn't find any existing issue or PR for Anthropic-direct WIF — only the Vertex/Azure ones cited above.

What part of LiteLLM is this about?

SDK (litellm Python package) — primary; Proxy — for config wiring.

LiteLLM is hiring a founding backend engineer, are you interested in joining us and shipping to all our users?

No

Twitter / LinkedIn details

https://www.linkedin.com/in/6matt

[erran]

Happy to see an issue opened up to track this I’d be interested in contributing towards supporting Claude WIF in LiteLLM. 🙇🏽‍♂️ Is this something you’ve already started @6matt?

[6matt]

that would be awesome @erran ! I'm not planning to implement myself

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.