Use WIF with Google Cloud

Any Google Cloud compute environment with access to the instance metadata server (Cloud Run, Cloud Functions, App Engine, Compute Engine (GCE), and GKE with Workload Identity) can request a Google-signed identity token for its attached service account. The token's issuer is https://accounts.google.com, and Anthropic can validate it directly through standard OIDC discovery, with no extra Google Cloud configuration required.

This guide shows how to register the Google issuer with Anthropic, bind a Google service account to an Anthropic service account, and have your workload exchange its identity token for a short-lived Claude API access token.

Prerequisites

• Familiarity with WIF concepts: service accounts, federation issuers, and federation rules.
• A Google Cloud project with a workload running on Cloud Run, Cloud Functions, App Engine, Compute Engine, or GKE.
• A user-managed Google service account attached to that workload (not the Compute Engine default service account).
• Permission to create service accounts, federation issuers, and federation rules in the Claude Console for your Anthropic organization.

Configure Google Cloud

Google issues identity tokens automatically to any workload with an attached service account. There is nothing to enable on the Google side beyond attaching the right service account, but the steps differ slightly between standard compute and GKE.

Configure Anthropic

Follow the setup walkthrough to register a federation issuer, create an Anthropic service account, and create a federation rule in the Claude Console. Use these Google Cloud-specific values.

Federation issuer: Google publishes its OIDC discovery document publicly, so use discovery mode. This single issuer covers every Google Cloud surface (Cloud Run, GCE, Cloud Functions, App Engine, and GKE with Workload Identity). Differentiate workloads with rules, not issuers.

{
  "name": "gcp",
  "issuer_url": "https://accounts.google.com",
  "jwks_source": "discovery"
}

Federation rule: Match on both the sub and email claims. email is the readable service-account address; sub is the service account's numeric unique ID, which Google never reuses, so pinning it protects the rule if the service account is deleted and a new one is later created with the same email. Find the unique ID with gcloud iam service-accounts describe SA_EMAIL --format='value(uniqueId)'.

{
  "name": "gcp-inference-worker",
  "issuer_id": "fdis_...",
  "match": {
    "audience": "https://api.anthropic.com",
    "claims": {
      "sub": "104892101234567890123",
      "email": "[email protected]"
    }
  },
  "target": {
    "type": "service_account",
    "service_account_id": "svac_..."
  },
  "workspace_id": "wrkspc_...",
  "oauth_scope": "workspace:developer",
  "token_lifetime_seconds": 600
}

Acquire and use the token

Inside your Google Cloud workload, fetch the identity token from the metadata server, exchange it at POST /v1/oauth/token, and use the returned bearer token to call the Claude API. Each Anthropic SDK handles the exchange and refresh loop for you when you supply a token-provider callable that returns a fresh identity token from the metadata server, as shown in the following examples.

Google identity tokens expire after roughly one hour. The SDKs re-invoke the token provider and re-exchange automatically before expiry. For shell scripts that run longer than the access token's expires_in, refresh on a timer and repeat the exchange.

Verify the setup

From inside your workload, decode the identity token and confirm the claims match your rule:

curl -sS -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://api.anthropic.com&format=full" \
  | jq -rR 'split(".")[1] | gsub("-";"+") | gsub("_";"/") | @base64d | fromjson'

Check that iss is https://accounts.google.com, aud is https://api.anthropic.com, and email matches the value in your federation rule. Then run the exchange from the previous section. A successful exchange returns an access_token beginning with sk-ant-oat01- and an expires_in value in seconds. On 400 invalid_grant, see Troubleshoot a failed exchange; the most common Google Cloud-side cause is the email claim missing (request the token with format=full so it is included).

Scope your rule

Lock the rule's match block to the narrowest scope that fits your use case:

• Match sub exactly: Set the full numeric unique ID in claims.sub and never use subject_prefix for Google tokens.
• Pin the email claim: Add claims.email alongside sub so both the stable ID and the readable address must match.
• Pin the audience: Set audience to the exact value you request from the metadata server so tokens minted for other consumers are rejected.
• Pin the project on GKE: For format=full tokens, add a condition such as claims.google.compute_engine.project_id == "my-project" to restrict the rule to one project's nodes.

Next steps

• Read the Workload Identity Federation page for the full resource model and SDK credential precedence.
• Add a separate federation rule per environment (production, staging) so you can revoke one without affecting the others.