Drop Your Static Claude API Keys: Moving CI and Production to Keyless Auth with Workload Identity Federation

Three things to register: service account, issuer, rule

Before any workload can federate, you create three resources in the Claude Console. Together they express "a token signed by issuer X, with claims that look like Y, may act as service account Z."

A service account (svac_...) is a non-human identity inside your organization. It represents who a federated token acts as. It has no email, no password, no Console login. It becomes active only when added to a workspace's members, and the minted token follows that workspace's rate limits and usage attribution, just like an API key.

A federation issuer (fdis_...) registers an OIDC IdP with your organization — declaring "JWTs signed by this provider may assert workload identity for my org." Its core config is the Issuer URL that exactly matches the JWT's iss claim, and how Anthropic fetches the public keys to verify signatures (most IdPs work with discovery).

A federation rule (fdrl_...) bridges an issuer and a service account: "when a JWT from issuer X satisfies condition Y, mint a token for service account Z with scope S." You can narrow by subject prefix, exact audience, exact claim values, or a CEL expression for complex logic. Make this as specific as your IdP's claims allow — a rule that matches too broadly grants more than you intend.

Rules are evaluated by ID. The client states which rule to use in the exchange request, and Anthropic verifies the JWT satisfies that rule's match criteria. There is no implicit rule search.

Exchanging the JWT for a short-lived token

The exchange itself is plain OAuth. The workload presents its IdP JWT to POST /v1/oauth/token using the RFC 7523 jwt-bearer grant. Anthropic verifies the signature against the registered JWKS, checks exp/nbf/iat, and matches against the rule you named. The response is a standard OAuth 2.0 token response containing a short-lived sk-ant-oat01-... token.

{
  "access_token": "sk-ant-oat01-xxxxxxxx...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "workspace:developer"
}

With the SDK you never write this exchange yourself. The recommended production pattern is to construct the client with no arguments and inject per-environment values via environment variables, so you can ship one container image everywhere.

from anthropic import Anthropic, WorkloadIdentityCredentials, IdentityTokenFile
 
# Explicit form shown; production prefers zero-arg construction + env injection
client = Anthropic(
    credentials=WorkloadIdentityCredentials(
        identity_token_provider=IdentityTokenFile(
            "/var/run/secrets/anthropic.com/token"
        ),
        federation_rule_id="fdrl_...",
        organization_id="00000000-0000-0000-0000-000000000000",
        service_account_id="svac_...",
        workspace_id="wrkspc_...",
    ),
)
 
message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
print(message.content[0].text)

Notice there is no api_key anywhere. The long-lived secret is gone from both the code and the image.

Calling Claude from GitHub Actions without a key

For an indie developer, CI is where WIF pays off most visibly. I run content generation across several sites with GitHub Actions and scheduled jobs, and the static key there was a long-standing weak point. The moment a key lives in repository secrets, it can leak through workflow logs or third-party Actions.

GitHub Actions can issue OIDC tokens, so registering it as a WIF issuer lets you authenticate with no key in secrets at all. The workflow needs only the id-token: write permission and a few lines to write the OIDC token to a file and hand it to the SDK via environment variables.

permissions:
  id-token: write   # required to mint the OIDC token
  contents: read
 
jobs:
  generate:
    runs-on: ubuntu-latest
    env:
      ANTHROPIC_ORGANIZATION_ID: ${{ vars.ANTHROPIC_ORG_ID }}
      ANTHROPIC_SERVICE_ACCOUNT_ID: ${{ vars.ANTHROPIC_SVAC_ID }}
      ANTHROPIC_WORKSPACE_ID: ${{ vars.ANTHROPIC_WORKSPACE_ID }}
      ANTHROPIC_FEDERATION_RULE_ID: ${{ vars.ANTHROPIC_RULE_ID }}
      ANTHROPIC_IDENTITY_TOKEN_FILE: ${{ runner.temp }}/anthropic_oidc.jwt
    steps:
      - uses: actions/checkout@v4
      - name: Mint OIDC token for Anthropic
        run: |
          # audience must match the rule's match.audience
          TOKEN=$(curl -sS \
            "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=anthropic" \
            -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
            | python3 -c 'import sys,json; print(json.load(sys.stdin)["value"])')
          printf '%s' "$TOKEN" > "$ANTHROPIC_IDENTITY_TOKEN_FILE"
      - run: pip install anthropic
      - run: python scripts/generate_article.py

Every value here is a vars entry — harmless identifiers — and not one of them is a secret. IDs like svac_... and fdrl_... carry no power on their own. Simply removing the key as an asset from CI made the mental weight of inventory much lighter. For the broader picture of wiring GitHub Actions to Claude, see GitHub Actions and Claude API automation.

The trap you will hit: the API key wins silently

This is the single most important thing in this article. Every SDK resolves credentials in the same five-tier order: constructor arguments, then ANTHROPIC_API_KEY / ANTHROPIC_AUTH_TOKEN, then an explicit ANTHROPIC_PROFILE, then the federation environment variables, then the implicit active profile. The first source that yields a credential wins.

The catch is that ANTHROPIC_API_KEY sits above the federation tiers. So if a stale key lingers anywhere in the environment, it silently shadows federation even when WIF is configured perfectly. No error, no warning. This is the hardest failure to spot: "I set it up, but it isn't being used."

Here is the no-downtime migration:

1. Configure federation in parallel. Leave the existing ANTHROPIC_API_KEY in place and confirm the rule matches your workload's token.
2. Smoke-test which credential wins. Run ant auth status inside the workload. At this stage the API key still wins, by precedence.
3. Unset ANTHROPIC_API_KEY everywhere it is injected — CI secrets, container env, shell profiles — then re-run ant auth status and confirm the federation source is selected.
4. Revoke the API key. Once the workload runs on the federated token, delete the key in the Console.

# Always confirm which tier was selected
$ ant auth status
# Example:
# Resolved credential source: ANTHROPIC_API_KEY (env)   <- key still winning
# ...
# Unset the key and re-check
$ unset ANTHROPIC_API_KEY
$ ant auth status
# Resolved credential source: workload identity federation (fdrl_...)  <- migrated

I personally nearly burned half a day on "I configured it but nothing changed" before I understood this precedence. Building the habit of running ant auth status first removes the trap almost entirely.

Designing token lifetime and refresh

Since these are short-lived tokens, understanding lifetime and refresh keeps production stable. The minted token's lifetime is the lesser of the rule's token_lifetime_seconds (default 3600, range 60–86400) and twice the remaining life of the IdP JWT you presented, with a 60-second floor. That second bound prevents the Anthropic token from outliving the upstream identity by more than a small margin.

The SDK handles refresh on two tiers. At expiry minus 120 seconds it attempts an advisory refresh; if the token endpoint is unreachable, the cached token is still valid for roughly 90 more seconds, so work continues. At expiry minus 30 seconds it performs a mandatory refresh, and a failure there raises an error because the cached token is too close to expiry to be safe.

Two design implications follow. First, setting token_lifetime_seconds too short increases exchange frequency; for long batch jobs, avoid extreme values while keeping the JWT's own lifetime in mind. Second, because the SDK re-reads ANTHROPIC_IDENTITY_TOKEN_FILE on every exchange, it transparently picks up rotated tokens (such as Kubernetes projected tokens) with no extra work. A long-running job that mysteriously fails auth partway through is often a symptom of missing this detail.

Where to start as a solo developer

WIF can look like heavyweight enterprise machinery, but the entry point is light. For interactive development, ant auth login lets you complete OAuth authorization in a browser and clear the key from your hands — so you stop leaving sk-ant-... in shell history and dotfiles. That alone is worth adopting.

For production and CI, I'd recommend moving one low-blast-radius workload at a time. WIF gives you a "no key held" design, but it is not a complete security story by itself: if the IdP that signs the JWT is weak, the whole chain is weak. Pair it with the conditional access and audit logging your IdP already supports for defense in depth. The idea of consolidating connectors and credentials into a single source of authority is a continuation of centralizing connector authorization — part of slowly folding away ad-hoc key handling.

A manageable next step is to switch your local environment to ant auth login and run ant auth status once to see where your credential comes from. When even one key leaves your environment, the operational landscape changes more than you'd expect. Thank you for reading.