Which claims must a cloud role's OIDC trust policy validate before it issues credentials to a CI job?
answer
- three claims, not one
- who signed it
- who it was addressed to
- which repo and which environment
- signature and expiry checked first
basics
~20 sA cloud trust policy checks the issuer that signed the token, the audience naming the intended recipient, and the subject identifying which repository, branch or environment the job ran in - after verifying the signature and expiry.
solid answer
~50 sThe cloud never trusts a build because of where the request came from; it trusts a signed OIDC token and the claims inside it. Three matter. The issuer (`iss`) names the identity provider that signed the token, and the cloud fetches that provider's public keys to verify the signature; pinning the exact issuer URL stops a lookalike provider standing in. The audience (`aud`) names who the token was minted for, so the cloud must require its own value and reject tokens addressed elsewhere. The subject (`sub`) names which workload it was - a structured string carrying the repository and the branch or environment. Signature, expiry and issuer are validated first, then the conditions on subject and audience, and only then does the exchange hand back short-lived credentials. Issuer alone trusts every repository that provider serves; subject alone trusts a token that was never addressed to you.
go deeper
Be ready to name the three claims and say in one line what each pins down: who signed the token, who it was addressed to, and which workload it describes. Knowing that the token is exchanged for short-lived credentials is expected.
Explain the order of validation - signature against the issuer's published keys, then issuer, audience and expiry, then the claim conditions - and why each check is not redundant with the others.
Show judgment about which claims to bind to. Argue for the environment or repository claims the provider mints over anything a contributor can set, and separate who may assume the role from what the role may do.
Own the standard: a documented minimum condition set every federated role must meet, exact matching by default, and a review path so nobody ships a role trusted on the issuer alone.
## What is actually being trusted Workload identity federation replaces a long-lived cloud access key stored in CI with a per-job exchange: the build presents a short-lived, signed OIDC identity token describing itself, and the cloud - if it likes what the token says - mints temporary credentials for a role. The interesting half is the cloud side, sometimes called the role trust policy, the workload identity pool, or the federated credential. It is an authorization decision made entirely on the contents of a signed JSON document. That document is a JWT: a header, a set of claims, and a signature. Nothing about the network connection identifies the caller. The token is a bearer token - whoever holds it can present it - so every guarantee has to come from claims and from the signature over them. ## The validation chain 1. **Signature.** The cloud resolves the issuer's OIDC discovery document, fetches its published signing keys, and verifies the token was signed by one of them. A token whose signature does not verify is worthless regardless of what it says. 2. **`iss` - the issuer.** The exact issuer URL is pinned in configuration. This answers *who vouches for this description of the workload*. It must be an exact match, not a suffix or substring match: an attacker who can stand up an issuer whose URL merely contains yours would otherwise be able to sign any claims they like. 3. **`aud` - the audience.** The recipient the token was minted for. A relying party is required to reject a token that does not name it. This is what stops a token that some other service legitimately received from being replayed against your cloud tenant. 4. **`exp` / `iat` / `nbf` - lifetime.** These tokens are minted with lifetimes measured in minutes. A leaked one is only useful while it lives, and only to something that accepts its audience. 5. **`sub` - the subject, plus other claims.** The subject is the workload's identity: for a CI platform it is typically a structured string that packs the repository and then either the branch or ref, or the deployment environment, into one value. Providers also mint additional claims - repository, ref, environment, workflow reference, actor, run identifiers - and a trust policy can condition on those individually as well as on `sub`. 6. **Credential minting.** Only after all of the above does the exchange return temporary credentials scoped to the role, with their own short expiry. ## Why all three, not one Each claim answers a different question, and dropping any one leaves a real hole: | Claim | Question it answers | What its absence permits | | --- | --- | --- | | `iss` | Who signed this description? | Any signer whose token you happen to accept | | `aud` | Who was it addressed to? | Replay by any other party that also holds a valid token | | `sub` | Which workload was it? | Every repository and branch that issuer serves | A trust policy that pins only the issuer is the classic beginner mistake: the issuer signs tokens for *every* project hosted on that platform, so "signed by the CI provider" means "anyone with an account there". A policy that pins only the subject accepts a token minted for some entirely different relying party that happens to describe the same workload. ## Choosing which claims to condition on Prefer claims the issuer mints from facts it controls - repository, environment, ref - over claims that reflect something a contributor can influence. Conditioning on an actor or a job name that anyone with write access can set moves the authorization decision into the hands of whoever can edit the repository. Where the provider exposes a deployment environment claim, that is usually the most stable and most meaningful thing to bind to, because it maps to the blast radius you actually care about. Also prefer exact equality over pattern matching. Every widened match - a prefix, a trailing wildcard - is delegating part of the decision to whatever else the pattern happens to catch, and those decisions are made once and then live for years. ## What this does and does not buy you What it buys: no long-lived cloud key sitting in a CI secret store to be leaked, rotated, or inherited by a contractor; credentials that expire on their own; and an audit record tied to a workload rather than to a shared machine user. What it does not buy: any limit on what the role can do once assumed. The trust policy decides *who may assume*; the permissions attached to the role decide *what they get*. A perfectly pinned subject on a role with administrator permissions is still an administrator in the hands of anyone who can make that repository build.
- These tokens are bearer tokens. What stops a leaked one being reused an hour later?Lifetime and addressing. The token carries an expiry measured in minutes, so it dies on its own, and the audience condition means only the relying party it was minted for will look at it in the first place. The credentials it buys are themselves temporary. None of that helps if the audience is a value everyone accepts, or if the trust policy tolerates a wide subject.
- Why is pinning the issuer alone not enough?Because the issuer signs tokens for every project it hosts, not just yours. Accepting anything that provider signed means anyone who can create a repository or a pipeline on that platform can mint a token your cloud will honour. The issuer establishes that the claims are authentic; the subject and audience conditions are what turn authentic claims into an authorization decision.
- Beyond the three, which claims are worth conditioning on?The ones the provider mints from facts a contributor cannot set: the repository, the deployment environment, and the reference to the workflow definition that ran. Avoid conditioning on values anyone with write access can choose, such as a job or actor name, because that hands the authorization decision to whoever can edit the repository.
saying these in an interview costs you the question
- Thinks validating the issuer alone identifies the repository
- Calls the OIDC identity token itself the cloud credential
- Treats the audience claim as optional boilerplate
- Believes the CI platform decides which role a job gets
- Assumes the trust policy also limits what the role can do