# workload-identity-federation

Source: https://startwithidentity.com/glossary/workload-identity-federation/
Last updated: 2026-09-29
License: content by Start with Identity. Cite the source URL.

---

Workload identity federation lets a workload authenticate to a cloud provider by presenting a short-lived token from an identity provider it already has, such as a CI/CD system or a Kubernetes cluster, instead of storing a long-lived secret or access key.

The workload obtains a signed [OIDC](https://startwithidentity.com/glossary/oidc/) token from its own platform (for example, the token GitHub Actions issues to each job), and the cloud validates the token's issuer, subject and audience against a trust configuration before exchanging it for temporary credentials. AWS supports this through IAM OIDC identity providers, Google Cloud through Workload Identity Federation, and Microsoft Entra through federated identity credentials on app registrations and managed identities. It removes the stored secret that leaks into repositories and tickets, which is the most common way cloud workloads are compromised. The main mistake is a trust condition that is too broad, such as accepting any branch or any repository in an organization, which lets an attacker who can run a job anywhere in scope assume the role.

See also: [workload identity](https://startwithidentity.com/glossary/workload-identity/), [token exchange](https://startwithidentity.com/glossary/token-exchange/), [SPIFFE](https://startwithidentity.com/glossary/spiffe/), [secrets in repositories and CI](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/)