Workload identity federation lets software that runs outside a cloud, such as a CI job, prove who it is with a signed token from its own platform and trade that token for short lived cloud credentials. No long term key is stored. The cloud trusts the platform, then checks the details.
The idea
Normally a pipeline reaches your cloud with a secret key you created and pasted into a settings page. Federation replaces the pasted secret with a conversation:
- The CI platform signs a token for the job: this is repository X, running on branch Y.
- The job sends that token to the cloud's token service.
- The cloud checks the signature against the platform's published keys.
- The cloud checks the claims against a trust rule you wrote.
- If everything matches, it returns credentials that expire.
Microsoft describes it as a trust relationship between an app and an external identity provider, letting an external workload access protected resources without managing secrets or certificates in supported scenarios.
Terms
| Term | Meaning |
|---|---|
| Identity provider (issuer) | The platform that signs tokens, such as your CI service |
| Subject (sub) | Who the token describes, for example a repository and branch |
| Audience (aud) | Which service the token is for |
| Trust policy or federated credential | Your rule about which tokens to accept |
| Temporary credentials | What you get back, valid for a limited time |
Same idea, different names
AWS calls it assuming a role with web identity. Its best practices page lists the web identity exchange as one way to deliver temporary credentials to workloads outside AWS, including managed CI/CD platforms. Microsoft calls the trust object a federated identity credential. GitLab and GitHub both issue the tokens, and each documents which claims they contain.
Why teams adopt it
- No stored secret to leak. Nothing in the repository or the secret store grants cloud access by itself.
- Expiry by default. AWS recommends relying on temporary credentials over long term ones where possible.
- Fine grained control. The trust rule can require a specific repository, branch, environment or protected ref.
- Clear audit trail. On AWS, CloudTrail logs the web identity role assumption and information from the identity provider.
What it does not do
Federation does not make a job safe. It proves where a job came from, not what the job will do. If a trusted repository runs malicious code, the code gets whatever the role allows. You still need least privilege, protected environments and review of workflow changes. A loose trust rule can also undo the benefit: GitHub's AWS guide notes a repository wildcard allows any branch, pull request merge branch or environment to assume the role.
Getting started
- Choose the lowest risk pipeline to move first.
- Register the platform as an identity provider in your cloud.
- Create a role with only the permissions that pipeline needs.
- Write an exact trust rule on audience and subject.
- Turn on logging so you can see assumptions.
- Move the next pipeline once the first runs cleanly.
Our guide to moving CI from access keys to OIDC walks through the cutover.
Quick check
Is federation the same as OIDC?
OIDC is the token format and protocol most CI platforms use. Federation is the broader idea of trusting an outside identity provider.
Does federation remove the need for least privilege?
No. It removes a stored secret, but the role's permissions still decide what a compromised job can do.
Safeguard does not manage your cloud accounts. It scans your code and dependencies, applies pull request policies and gates, and automates compliance evidence. Free scan: gold.safeguard.sh/scan.
Sources
- Microsoft Learn: Create a trust relationship between an app and an external identity provider
- AWS IAM User Guide: Security best practices in IAM
- AWS IAM User Guide: Logging IAM and AWS STS API calls with AWS CloudTrail
- GitHub Docs: OIDC in Amazon Web Services
Last reviewed: 19 October 2026.
