In a CI/CD pipeline, what is OIDC workload-identity federation, and what does the pipeline actually exchange for a cloud credential?

## The problem federation solves A pipeline that deploys needs to authenticate to something outside itself — a cloud account, a registry, a package index. The traditional answer is to create a service account, generate a long-lived access key, and paste it into the CI platform's secret store. That key is a bearer credential: whoever holds the bytes *is* the service account, from any network, until a human rotates it. It sits in the CI platform's database, in the environment of every job that references it, and in the memory of every process that job starts. Because CI systems typically hold deploy-grade permissions across an estate, and because pipeline definitions are editable by anyone who can open a merge request, that store is one of the highest-value targets in most organisations. A leaked key is usually discovered late, and rotation is a coordinated change across every pipeline that used it. ## What "federation" means here Federation means two parties trust each other without sharing a secret. The CI platform runs an OpenID Connect identity provider: it publishes a discovery document (conventionally at `/.well-known/openid-configuration`) which points at a `jwks_uri` serving its public signing keys. On request from inside a job, it mints a JSON Web Token signed with the matching private key. The token's claims describe *that run*, not a person: ```json { "iss": "https://ci.example.com", "aud": "my-cloud-sts", "sub": "repo:acme/payments:ref:refs/heads/main", "iat": 1730000000, "exp": 1730000600 } ``` Platforms add their own claims alongside the standard ones — repository, ref, environment name, workflow or pipeline identity, run id. The token lives for minutes and is worthless unless some relying party has been configured to trust that issuer. ## The exchange, step by step 1. The job asks the CI platform for an identity token, naming the audience it wants the token minted for. 2. The job presents the token to the cloud's token-exchange endpoint. On AWS this is `sts:AssumeRoleWithWebIdentity`; the other major clouds have equivalent workload-identity or federated-credential features. 3. The cloud fetches the issuer's JWKS over TLS and verifies the token's signature, expiry, and that the issuer is one it has been configured to trust. 4. The cloud checks the `aud` claim matches the audience registered for that trust configuration. 5. The cloud evaluates the condition attached to the role: does the `sub` claim match the pattern the administrator pinned? 6. On success it returns short-lived credentials — usually an hour or less — carrying only that role's permissions. No step in that flow involves a value that was stored anywhere before the job started. ## What it buys and what it does not It buys: no cloud secret at rest in CI; a theft window measured in minutes rather than months; an identity per pipeline run rather than one shared robot account; and an audit trail that names the repository and branch rather than "the CI user". It does not buy least privilege. The role's permission set is unchanged by how you authenticated to it; a federated role with administrator rights is still an administrator. It does not protect you from a pipeline that is itself compromised: an attacker who can execute a step in a trusted context can request the token and receive exactly the same credentials — federation removes the *stored* secret, not the *ability to obtain* a credential from inside the build. And it only applies to relying parties that implement it; plenty of third parties still accept nothing but an API key. ## Where the real design work sits Two fields carry almost all of the security value. The **audience** stops a token minted for one relying party being replayed at another. If every relying party accepts the same generic audience, a token you hand to a minor service can be forwarded to your cloud. Set a distinct audience per relying party and pin it in the trust configuration. The **subject** decides *which runs* may assume the role. This is where teams get it wrong most often, and it deserves treating as a first-class access-control decision rather than a copy-paste from a quickstart: a subject condition that names only the repository lets any branch in that repository assume the role, which is a very different grant from what most people believe they configured. ## What to say in an interview Name the three verified things — issuer, audience, subject — say the token is short-lived and describes the run, and be explicit that the outcome is temporary credentials rather than the token itself being usable against the cloud API.