Workload Identity Federation: Cloud Access Without Stored Keys

Workload identity federation lets a program outside a cloud trade a token its own environment issued for short-lived credentials in that cloud. No access key or client secret is created, stored or rotated.

Updated Nov 15, 2026

Request More Info

Workload identity federation is a trust set up in advance between a cloud and an outside identity provider, such as a CI/CD system, a Kubernetes cluster or another cloud. At run time the workload presents a signed token from that provider. The cloud checks the signature, issuer, audience and subject against the trust rule, and returns credentials that expire in minutes or hours. The workload never holds a long-lived key.

AWS, Google Cloud and Microsoft Entra ID all offer it under slightly different names. The mechanics are the same in each.

How the exchange works

Trust, once. An administrator registers the outside issuer (its OIDC discovery URL or keys) and writes a rule: which sub, aud and other claims may use which role or identity.
Token from home. The workload asks its own environment for a token. A GitHub Actions job asks GitHub; a Kubernetes pod reads its projected service account token.
Exchange. The workload sends that token to the cloud’s token service.
Check. The cloud fetches the issuer’s public keys, verifies the signature and expiry, and matches the claims against the rule.
Short-lived credentials. The cloud returns temporary credentials scoped to one role or identity. The workload uses them, and they expire on their own.

Nothing in these steps is a secret the workload stores. A stolen pipeline log holds, at most, a token that expires soon.

One pipeline, three clouds

Acme Corp’s deployment job billing-api runs in GitHub Actions and deploys to all three clouds. It receives one token from GitHub. Each cloud needs its own trust rule to accept it.

The token’s relevant claims (format from GitHub’s documentation; organization and repository fictional):

{
  "iss": "https://token.actions.githubusercontent.com",
  "sub": "repo:acme-corp/billing-api:ref:refs/heads/main",
  "aud": "sts.amazonaws.com"
}

The AWS trust policy that accepts it, and only from the main branch of that repository:

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
    "token.actions.githubusercontent.com:sub": "repo:acme-corp/billing-api:ref:refs/heads/main"
  }
}

The same idea in each cloud:

	AWS	Google Cloud	Microsoft Entra ID
Name used	OIDC federation	Workload Identity Federation	Workload identity federation
Trust object	IAM OIDC identity provider plus a role trust policy	Workload identity pool and pool provider	Federated identity credential on an app registration or user-assigned managed identity
How claims are matched	Policy condition keys on `aud` and `sub`	Attribute mapping and a CEL attribute condition	`issuer`, `subject` and `audience`, exact and case-sensitive
Exchange call	STS `AssumeRoleWithWebIdentity`	Security Token Service (OAuth 2.0 token exchange)	Client credentials flow with the outside token as the assertion
What comes back	Access key ID, secret key and session token	A short-lived OAuth 2.0 access token, optionally used to impersonate a service account	An access token
Lifetime	1 hour by default; 15 minutes up to the role’s maximum (1 to 12 hours)	Short-lived (no fixed value stated)	Not stated on the overview page
Outside sources named	GitHub Actions and any OIDC provider	AWS, Azure, X.509 certificates, Active Directory, GitHub, GitLab, any OIDC or SAML 2.0 provider	Kubernetes, GitHub Actions, Google Cloud, AWS, SPIFFE

Where federation goes wrong

The weak point is the trust rule, not the cryptography.

A subject that matches too much. AWS warns that a GitHub trust without a specific sub lets workflows from organizations outside your control assume the role. IAM now refuses a GitHub trust policy whose sub condition is missing or only a wildcard, and STS refuses HCP Terraform roles that do not check app.terraform.io:sub.
Subject formats change. GitHub’s documentation (read 2026-11-15) says repositories created after July 15, 2026 use an immutable default subject format that includes owner and repository IDs. A rule written for the older repo:org/repo:... form will not match a new repository.
Exact matching. Entra compares issuer, subject and audience case-sensitively. A trailing slash in the issuer is enough to fail.
Key sets. Entra keeps only the first 100 signing keys it downloads from an issuer’s OIDC endpoint.
No loops. Tokens issued by Entra ID cannot be used as the outside token in Entra’s own federated flow.

Workload versus workforce identity federation

	Workload identity federation	Workforce identity federation
Who signs in	Software: pipelines, pods, VMs in another cloud	People, through their organization’s identity provider
Token presented	A workload token from the environment	An OIDC or SAML sign-in from the workforce IdP
Typical use	Deploying, calling cloud APIs from outside	Console and CLI access without separate cloud accounts

Google Cloud states the split directly: workforce federation federates user identities, workload federation federates workload identities.

Where SPIFFE fits

SPIFFE and SPIRE give every workload a short-lived identity document, an SVID, inside your own environment. Workload identity federation is how that identity crosses into a cloud. Microsoft Entra ID lists SPIFFE workloads as a supported source, so a JWT-SVID can be exchanged for an Entra access token with no stored secret.

AI agents and non-human identity

An AI agent is a workload, so federation can give it cloud credentials without a key on disk. It answers one question: which program is calling.

The missing half. Federation does not say which person the agent acts for, or what that person agreed to.
Delegation. That needs a token that names both, as in OAuth token exchange, where the person is sub and the agent is act.
Ownership and end dates. Workloads, keys and agents are all non-human identities that need an owner, a scope and an expiry.

AI agent identity covers the controls an agent needs beyond a workload credential.

SSOGEN and agent identity

SSOGEN registers each AI agent as its own identity with up to five named owners, a review or expiry date and an explicit list of applications and scopes. An agent proves itself with a key pair; SSOGEN refuses a registration that contains a private key.

Every token is bound to the agent’s key, which the agent proves with DPoP on each request, so a copied token is useless elsewhere. Each token lives about four minutes. The AI agents guide has the details.

Questions people ask

What is workforce Identity Federation in GCP?

Workforce Identity Federation lets employees and partners sign in to Google Cloud with an outside identity provider over OIDC or SAML, with no Google account for each person. It federates people. Workload Identity Federation is its counterpart for software: it federates pipelines, pods and programs in other clouds.

What is the difference between SSO and federated identity?

Single sign-on means one sign-in opens many applications. Federated identity means one organization trusts identities issued by another. SSO can run inside one organization with no federation; federation is what lets SSO cross organizations or clouds. Workload identity federation applies the same trust model to software instead of people.

What is Microsoft Entra workload identity?

A workload identity in Microsoft Entra ID is an identity for software: an app registration, its service principal or a managed identity. Workload identity federation lets such an identity trust tokens from GitHub, Kubernetes, Google Cloud, AWS or SPIFFE, so the workload gets Entra access tokens without a client secret or certificate.

What is federated SSO vs SSO?

Federated SSO is single sign-on where the identity provider and the application belong to different trust domains, linked by SAML or OpenID Connect. Plain SSO only requires that one sign-in covers several applications. Most enterprise SSO to SaaS products is federated. See federated identity for the model.

Is workload identity federation more secure than service account keys?

Yes, for most workloads. There is no long-lived secret to leak, rotate or forget, and each credential expires on its own. The security then rests on the trust rule: a subject condition that is too broad lets workloads you do not own exchange their tokens for your credentials.

Where to go next

The identity layer underneath. SPIFFE and SPIRE for workload identity inside your network.
Software identities as a class. Non-human identity compares service accounts, keys, workloads and agents.
Agents. AI agent identity and DPoP, the proof that binds a token to a key.
More explainers. Browse Learn.

Sources, all read 2026-11-15: AWS IAM: OIDC federation, AWS IAM: create a role for OIDC federation, AWS STS: AssumeRoleWithWebIdentity, Google Cloud: Workload Identity Federation, Google Cloud: Workforce Identity Federation, Microsoft Entra: workload identity federation, GitHub: OpenID Connect in Actions.