IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Workload identity federation — no stored secrets
Every night Priya's build pipeline deploys the app to the cloud. The old way was to paste a long-lived cloud key into the pipeline settings. That key never expires, and it leaks easily. Your goal: let the pipeline prove who it is without holding any secret.
- A stored cloud key never expires and leaks easily.
- The CI system already gives each job a signed token.
- The cloud swaps that token for credentials that last about an hour.
- The trust policy must pin the repo and branch, not just the issuer.
The problem with the stored key
A long-lived cloud key works like a password for your whole account. It sits in a settings box that many builds, forks and contractors can reach. It does not expire, so a copy stolen today still works next year. A federated identity stores nothing and lasts about 1 hour.
A new teammate copies the pipeline files into a public code repo. The cloud key goes with them. Bots scan public repos all day. Researchers have seen a leaked key used within minutes. By Monday, strangers have run costly machines on the company's bill. With federation, a copied pipeline file holds no key. There is nothing to steal.
The pipeline already has an identity
Priya's CI system gives every running job a short-lived, signed OIDC token. It says: "I am this pipeline, in repo acme/website, on branch main." The CI provider signs it. You can check it against the provider's public keys, as in the tokens lesson. GitHub Actions is a common example. Many CI systems offer the same.
So the pipeline can already prove what it is. The cloud only has to believe the proof.
Swap the token for cloud credentials
Workload identity federation makes the cloud trust that outside token. You write a trust policy in the cloud. It is the cloud side of the federation trust you met earlier. It names the issuer and the claims that must match. For example: accept tokens from Priya's CI, but only for repo acme/website and branch main.
The deploy then runs in five steps:
- The CI system gives the job a signed token.
- The job shows the token to the cloud.
- The cloud checks the signature with the CI provider's public keys.
- The cloud checks the repo and branch claims against the trust policy.
- The cloud returns credentials that expire in about an hour.
This swap is a token exchange, like the token-exchange lesson. No secret is stored, so nothing on disk can leak.
The classic mistake: trust that is too loose
The danger is in the trust policy, not in the swap. The CI provider is the same issuer for everyone's jobs. That includes an attacker who forks your repo and runs a pipeline of their own.
Say your policy checks only "issued by this CI provider". Then any fork's token passes, and a stranger's build takes your role. So pin the claims that name your pipeline: the repo, the branch and, where you can, the environment.
The issuer alone is never enough. "Trust tokens from the CI provider" means trusting everyone's forks. Pin the repo and the branch. Check the audience too. That is the service the token was made for. Review these conditions like a firewall rule.
Go deeper: what to pin, with a GitHub example (as of October 2026)
GitHub tokens carry claims such as sub, repository, ref and environment. GitHub says you must set at least one condition. Then untrusted repositories cannot get tokens. The example token in its documentation lives for 5 minutes. The cloud credentials you get back last longer, often about an hour.
For repositories created on or after 15 July 2026, GitHub's default sub includes the owner and repository IDs. Older repositories keep the old format unless they opt in. Your trust policy must match the format your repository uses.
Go deeper: every cloud does the swap its own way
Some clouds use the standard token exchange (RFC 8693) for this step. Others use their own call that works the same way. In both, the cloud checks the signature first. Then it checks the claims. Only then does it return credentials. The same pattern works for virtual machines, containers and other clouds. The next lessons show two more uses.
🧪 Interactive lab — enable JavaScript to play with this one.
Analyze a CI-to-cloud federation trust for conditions that are too broad with OIDC Federation. Then build and inspect the swap itself with the Token Exchange toolkit.