claudekit / updates / workload-identity-federation
[ NEW · ]

Workload Identity Federation is now generally available on the Claude Platform

Workload Identity Federation is generally available on the Claude Platform, letting developers authenticate with short-lived, scoped credentials from OIDC-compliant identity providers instead of static API keys. Federation rules bind external identities — AWS IAM, GCP, Azure, Kubernetes, GitHub Actions, Okta — to service accounts that issue tokens at request time across all Claude API endpoints.

Official announcement →

This article is a summary based on official documentation.

Overview

Workload Identity Federation (WIF) is now generally available on the Claude Platform, removing the need for static API keys. A workload presents its own OIDC-compliant credentials, the Claude Platform verifies them, and issues short-lived, scoped credentials at request time — so you never have to handle static Anthropic credentials.

Key features

  • No more static API keys — replaced by short-lived credentials

    Static API keys have to be created, rotated, and managed, and can be leaked. WIF removes the need to handle static Anthropic credentials entirely, authenticating with short-lived, scoped credentials issued at request time.

  • OIDC-based federation — bind external identities to service accounts

    Federation rules bind external identities to service accounts. When a workload requests access, the Claude Platform verifies the signed OIDC token, matches its claims against the federation rules, and issues a short-lived access token bounded by the service account’s roles. All exchanges and requests are recorded in audit logs.

  • Broad identity provider compatibility

    WIF works with any OIDC-compliant identity provider, including AWS IAM roles, GCP service accounts, Kubernetes service accounts, Azure managed identities, GitHub Actions tokens, and Okta.

  • Service accounts — its own identity and audit trail instead of a shared key

    Rather than many workloads sharing one API key, each gets a service account with its own identity, roles, and audit trail.

  • Covers all Claude API endpoints

    WIF covers all Claude API endpoints, including when accessing them through the first-party SDKs and Claude Code.

Notes

  • Gradual migration is supported — existing API keys work alongside WIF, so you can move over in stages rather than all at once.
  • Guided setup in the Claude Console — the Claude Console offers a guided setup flow with validation and testing to help configure federation rules.
  • Audit logging — every token exchange and request is recorded in audit logs, so you can trace which identity accessed the platform and when.
§ 4

Frequently Asked Questions

frequently asked
§ 4.1
What's new with this update?
Workload Identity Federation (WIF) is now generally available on the Claude Platform. Instead of static Anthropic API keys, workloads authenticate using OIDC-compliant credentials and receive short-lived, scoped tokens issued at request time.
§ 4.2
Which identity providers are supported?
WIF works with any OIDC-compliant identity provider, including AWS IAM roles, GCP service accounts, Kubernetes service accounts, Azure managed identities, GitHub Actions tokens, and Okta.
§ 4.3
What does it cover?
WIF covers all Claude API endpoints, including access through the first-party SDKs and Claude Code.
§ 4.4
Can I keep using existing API keys?
Yes. Existing API keys work alongside WIF, so you can migrate gradually.
§ 4.5
How do I set it up?
Federation rules bind external identities to service accounts. The Claude Console provides a guided setup flow with validation and testing.
§ 4.6
Where can I find the official announcement?
See the Claude blog post 'Secure access to the Claude Platform with Workload Identity Federation' at claude.com/blog/workload-identity-federation.