Workload Identity Federation and OIDC Token Exchange for CI/CD and Hybrid Cloud

#Start here: the basics in plain words

A CI job that deploys to the cloud needs to prove to the cloud who it is. The old way was to give it a long-lived secret, an AWS access key or a GCP service-account JSON file, stored in the CI system's secret store. That secret works forever, from anywhere, for anyone who copies it, and CI systems are the place where secrets get copied most: into logs, into caches, into memory dumps, into forks.

Workload identity federation replaces the stored secret with a signed statement the CI platform makes about the job: "this is run 18223019 of repository acme/app, on branch main, in the deploy workflow, started 30 seconds ago". The cloud has been told in advance to trust statements signed by that platform, and to hand out short-lived credentials only when the statement matches a rule you wrote. Nothing is stored. The job proves an identity instead of possessing a secret.

The signed statement is an OpenID Connect (OIDC) ID token, which is a JSON Web Token (JWT): three base64 blobs separated by dots, the last of which is a signature over the first two. The cloud verifies that signature with the platform's published public keys, then reads the claims inside.

Memory hook

"the token is a signed résumé, the trust policy is the hiring rule." The platform writes the résumé and signs it; the cloud checks the signature, then checks the résumé against your rule. Every failure on this page is either a forged résumé the verifier accepted, or a rule loose enough that the wrong résumé matched.

#OIDC Protocol Mechanics and the STS Exchange Flow

#What is this?

Three standards stacked: JSON Web Signature (RFC 7515) defines the signed envelope, JSON Web Token (RFC 7519) defines the claims inside it, and OIDC Discovery defines how a verifier finds an issuer's keys from its URL. OAuth 2.0 Token Exchange (RFC 8693) describes swapping one token for another, which is what the cloud STS does.

#Why it matters

Interviewers want to hear the exact sequence, because each step is a place a real system has been broken: discovery (fetching keys from the wrong place), signature (wrong algorithm), claims (wrong issuer or audience), and matching (a wildcard that was too wide).

#How it works

The discovery chain: the issuer URL plus /.well-known/openid-configuration returns a JSON document whose jwks_uri field says where the public keys are.

$ curl -s https://token.actions.githubusercontent.com/.well-known/openid-configuration | jq '{issuer, jwks_uri, id_token_signing_alg_values_supported, claims_supported}'
{
  "issuer": "https://token.actions.githubusercontent.com",        ← must equal the iss claim in every token, byte for byte
  "jwks_uri": "https://token.actions.githubusercontent.com/.well-known/jwks",   ← the only place keys may come from
  "id_token_signing_alg_values_supported": ["RS256"],              ← the verifier should accept exactly this and nothing else
  "claims_supported": ["sub","aud","exp","iat","iss","jti","nbf","ref","repository","repository_id","repository_owner","repository_owner_id","run_id","run_number","run_attempt","actor","actor_id","workflow","workflow_ref","job_workflow_ref","head_ref","base_ref","event_name","ref_type","environment","runner_environment","sha", …]
}

A decoded GitHub Actions ID token, with the claims that matter annotated:

Buildkite's token has the same shape with its own names: issuer https://agent.buildkite.com, subject organization:acme:pipeline:app:ref:refs/heads/main:commit:<sha>:step:deploy, and claims such as organization_slug, pipeline_slug, build_branch, build_number, step_key, agent_id and runner_environment. The default audience is https://buildkite.com/<org> and the default lifetime is five minutes.

The exchange itself, on AWS:

sequenceDiagram
  participant J as CI job
  participant G as GitHub OIDC issuer
  participant S as AWS STS
  participant I as IAM role trust policy
  J->>G: POST token request<br/>(runtime URL + bearer, aud=sts.amazonaws.com)
  G-->>J: ID token (JWT, RS256)
  J->>S: AssumeRoleWithWebIdentity<br/>(RoleArn, WebIdentityToken, DurationSeconds)
  S->>G: GET /.well-known/jwks (cached)
  S->>S: Verify signature, iss, aud, exp
  S->>I: Evaluate Condition on<br/>token.actions.githubusercontent.com:sub / :aud
  I-->>S: Allow
  S-->>J: AccessKeyId, SecretAccessKey,<br/>SessionToken (expires)

Two things people get wrong about this diagram:

In practiceFetching and decoding a token inside a GitHub Actions job. The two environment variables are set only when the job has id-token: write, and any step in that job can read them, which is the ambient-token problem covered later:

$ curl -sS -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
    "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=sts.amazonaws.com" | jq -r .value > /tmp/t
$ cut -d. -f2 /tmp/t | base64 -d 2>/dev/null | jq '{iss,sub,aud,repository_id,job_workflow_ref,event_name,runner_environment,exp}'
{
  "iss": "https://token.actions.githubusercontent.com",
  "sub": "repo:acme/app:environment:prod",                     ← the environment form: a reviewer approved this deployment
  "aud": "sts.amazonaws.com",
  "repository_id": "74213",                                    ← pin this, not the name
  "job_workflow_ref": "acme/app/.github/workflows/deploy.yml@refs/heads/main",
  "event_name": "push",
  "runner_environment": "github-hosted",
  "exp": 1761342000
}

🎯

On the job. When you review a pipeline, ask for the decoded sub of a real token and the trust policy side by side. Nine times out of ten the policy was written from documentation and the token's actual subject is a different form (branch vs environment vs pull request). Mismatches get "fixed" by loosening the policy to a wildcard, which is the bug you are there to catch.

#Cryptographic Verification Pipeline

#What is this?

What a verifier must do, in order, before it believes a single claim. Cloud providers do this for you; you do it yourself when you write a sidecar, an internal API gateway, or a Vault-like broker that accepts CI tokens.

#Why it matters

Every famous JWT vulnerability is a verifier that did these steps out of order or let the token choose how it would be verified. The token is attacker-controlled input until the signature check passes, and the signature check itself must not depend on anything inside the token except the key identifier.

#How it works

The attacks, each explained from zero:

#Algorithm confusion (RS256 to HS256)

The piecesRS256 is an asymmetric signature: the issuer signs with a private key, everyone verifies with the public key. HS256 is a symmetric MAC: one shared secret both signs and verifies. The JWT header carries an alg field saying which one was used.

What went wrongOlder libraries had a single verify(token, key) call that read alg from the token and did what it said. An attacker took the issuer's public key, which is public, built a token with alg: HS256, and computed an HMAC using the public key bytes as the secret. The library saw HS256, used the key it was given (the public key) as the HMAC secret, and the MAC matched.

Why it's badThe attacker mints any claims they like, including sub: repo:acme/app:environment:prod, and the verifier accepts them. This was CVE-2015-9235 in the Node jsonwebtoken library and the same bug appeared in several other libraries that year.

LessonThe verifier chooses the algorithm from configuration. Keys are typed: an RSA public key can never be handed to an HMAC routine. Modern libraries enforce both; your code must still pass an explicit algorithm list.

#alg: none

The piecesThe JWS specification allows an "unsecured" JWT with alg: none and an empty signature, intended for contexts where integrity is provided elsewhere.

What went wrongLibraries that supported none by default accepted a token with the signature stripped as valid.

LessonAllowlist, do not denylist: ["RS256"], not "anything except none".

#Psychic Signatures (CVE-2022-21449)

The piecesAn ECDSA signature is two numbers, r and s. The verification equation involves dividing by s and multiplying by r; the standard requires both to be in the range 1 to n−1, where n is the curve order.

What went wrongJava 15 through 18, before the April 2022 critical patch update, rewrote ECDSA verification and forgot the range check. A signature with r = 0 and s = 0 made the verification equation trivially true: the "proof" was that zero equals zero.

Why it's badAny ES256-signed JWT, SAML assertion or WebAuthn response could be forged with an all-zero signature against a verifier running an affected Java. OIDC issuers that sign with ES256 were directly exposed.

LessonSignature verification is not a solved problem you can ignore; pin library versions, run the test vectors, and prefer issuers that publish which algorithms they use so you can restrict yours.

#Header-driven key fetching (jku, x5u, kid injection)

The piecesThe JWS header may carry jku (a URL to a JWKS) or x5u (a URL to a certificate), and kid is a free-form string.

What went wrongVerifiers that fetched keys from the URL in the header let the attacker supply their own key. Verifiers that used kid as a file path or SQL fragment got path traversal or injection.

Lessonkid is only ever a lookup key into a JWKS you fetched from a URL you configured. jku and x5u are ignored.

In practiceA verifier in Go using the go-oidc library, which already pins the algorithm list, fetches keys from the pinned discovery document and refuses jku. The lines that matter are the configuration ones:

provider, err := oidc.NewProvider(ctx, "https://token.actions.githubusercontent.com") // ← discovery from a constant, not from the token
verifier := provider.Verifier(&oidc.Config{
    ClientID:             "internal-artifact-gateway",            // ← aud must contain exactly this
    SupportedSigningAlgs: []string{oidc.RS256},                    // ← allowlist; header alg is ignored otherwise
})
idTok, err := verifier.Verify(ctx, rawToken)                        // ← signature, iss, aud, exp, nbf (with small skew) all checked here
if err != nil { return deny(err) }
var c struct {
    Sub, RepositoryID, JobWorkflowRef, RunnerEnvironment string     `json:"sub"` // tags elided for brevity
}
if err := idTok.Claims(&c); err != nil { return deny(err) }
if c.RepositoryID != "74213" || c.JobWorkflowRef != "acme/app/.github/workflows/deploy.yml@refs/heads/main" { return deny(...) }  // ← semantic rules only after crypto

The TypeScript equivalent with jose has the same shape: createRemoteJWKSet(new URL(jwksUri)) from a constant, then jwtVerify(token, jwks, { issuer, audience, algorithms: ['RS256'] }), then your claim checks.

🎯

On the job. In code review, search for decode( without verify(, for algorithms lists that are missing or contain more than one entry, for any JWKS URL built from a string that came out of the request, and for a kid used in anything other than a map lookup. Each is a finding regardless of what the surrounding code intends.

#JWKS Cache Management and Key Rotation

#What is this?

Issuers rotate signing keys. A verifier that fetched the JWKS once at startup will reject every token after the rotation; one that fetches on every request will fall over, or be used as a denial-of-service amplifier, and becomes an SSRF (server-side request forgery) risk if the URL is ever influenced by input.

#Why it matters

This is the operational half of the verification question, and the one that causes outages. A good answer shows you know the failure modes in both directions: too stale and you fail closed at 3am, too eager and you are a weapon.

#How it works

In practiceA JWKS with two keys during a rotation, and the log line a healthy verifier emits when it meets a new kid:

$ curl -s https://token.actions.githubusercontent.com/.well-known/jwks | jq '.keys[] | {kid, kty, alg, use}'
{ "kid": "1F2AB834…", "kty": "RSA", "alg": "RS256", "use": "sig" }   ← current (values illustrative)
{ "kid": "38826b17…", "kty": "RSA", "alg": "RS256", "use": "sig" }   ← previous, still valid for in-flight tokens

# verifier log
level=info msg="jwks refresh" issuer=token.actions.githubusercontent.com reason=unknown_kid kid=1F2AB834… keys_before=1 keys_after=2 next_allowed_refresh=60s   ← one refresh, then rate-limited

📰

Real incident — GitHub certificate change breaks AWS federation (2023). For years, creating an AWS IAM OIDC provider required pasting the SHA-1 thumbprint of the issuer's TLS certificate chain, and when GitHub's intermediate certificate changed in early 2023 many pipelines broke until administrators added a second thumbprint. AWS then changed the design: it now verifies the JWKS endpoint's TLS certificate against its own trusted root store and falls back to the configured thumbprints only when the issuer uses a certificate from an unknown CA. The lesson is general: pinning a leaf or intermediate certificate for a key-distribution endpoint trades a theoretical attack for a guaranteed future outage; pin the issuer URL and verify TLS normally.

🎯

On the job. Load-test the verifier with tokens carrying a random kid. If the JWKS endpoint sees one outbound request per inbound token, you have found an amplifier and a latency bug at once. Then pull the network and confirm it keeps serving from cache for a while and alerts, rather than either denying everything instantly or serving forever.

#Standard Claim Validation Logic

#What is this?

After the signature, the registered claims: iss, aud, exp, nbf, iat, jti. Each has a correct comparison and a tempting wrong one.

#Why it matters

These are cheap string and integer checks, which is why they get skipped or done loosely. A loose iss check lets a token from a different issuer with the same key format through; a loose aud check lets a token minted for the wiki unlock production.

#How it works

In practiceThe validation function's failure messages, which double as your test cases. Each line corresponds to a bug that has shipped somewhere:

deny: iss mismatch        got="https://token.actions.githubusercontent.com/" want="https://token.actions.githubusercontent.com"   ← trailing slash; exact match caught it
deny: aud missing         got=["https://github.com/acme"] want="internal-artifact-gateway"   ← default audience; the workflow forgot audience=
deny: token expired       exp=1761342000 now=1761342130 skew=60s                              ← 130 s late; 60 s skew refused it
deny: nbf in future       nbf=1761342300 now=1761342000                                       ← clock on the issuer side? investigate before raising skew
deny: jti replay          jti=a3f9c1… first_seen=12s_ago                                      ← the same token presented twice

🎯

On the job. Clock skew tickets are a smell. When someone asks to raise the allowance "because tokens keep expiring", find out why the token takes that long to be presented; usually a step is minting the token at the start of a long job and exchanging it at the end. Fix the ordering, not the window.

#Subject Claim Anatomy and Wildcard Traps

#What is this?

The sub claim is where authorisation actually happens: it is the one claim both AWS and GCP let you match on by default, and its structure invites prefix matching that is wider than it looks.

#Why it matters

This is the single most common real-world misconfiguration in CI-to-cloud federation, and the question interviewers ask most often in this area. A trust policy is an IAM policy; a wildcard in it is a wildcard in who can be your production role.

#How it works

What the subject forms mean, and how each can be matched too loosely:

Names versus IDs: repository is acme/app. If the repository is deleted or transferred and a new repository with the same name appears under the same owner, it inherits every trust policy written against the name. repository_id (74213) and repository_owner_id (65) are numeric and never reused, which is why GitHub moved the default subject to the immutable form repo:acme@65/app@74213:ref:refs/heads/main for repositories created after 15 July 2026, and why custom subject templates let older repositories opt in.

In practiceThe dangerous policy next to the safe one. Both "work" in the demo; only one survives an insider or a compromised dependency:

"Condition": {
  "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" },
  "StringLike":   { "token.actions.githubusercontent.com:sub": "repo:acme/*" }          ← any repo in the org; a new sandbox repo is now a prod deployer
}

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
    "token.actions.githubusercontent.com:sub": "repo:acme@65/app@74213:environment:prod"   ← immutable IDs + a reviewed environment; nothing else matches
  }
}

If you cannot yet use the immutable subject, customise the subject template to include repository_id and job_workflow_ref (include_claim_keys), so the policy can pin both the repository and the reviewed workflow file rather than a name anyone can recreate.

📰

Real incident — Ultralytics on PyPI (2024). The popular ultralytics Python package shipped malicious releases in December 2024 that ran a cryptominer on install. Attackers did not steal a PyPI password: they exploited a pull_request_target workflow that interpolated a fork's branch name into a shell command, ran their code inside the trusted repository's context, and from there tainted the release pipeline that publishes to PyPI. The identity federation worked exactly as designed; the workflow that held the identity was the weak point. The lesson: an OIDC identity is only as trustworthy as every step that can execute inside the job that mints it.

🎯

On the job. aws iam list-roles then, for each role trusting token.actions.githubusercontent.com, print the sub condition. Anything with StringLike and a *, or any role with only an aud condition and no sub at all (which accepts tokens from any GitHub repository on earth), is a critical finding. The GCP equivalent is listing workload identity pool providers and reading their attribute conditions.

#Cloud Provider Trust Boundary Configuration

#What is this?

AWS and GCP both accept external OIDC tokens, but they expose the token differently: AWS gives you a few condition keys inside an IAM trust policy; GCP gives you a programmable mapping layer in CEL (Common Expression Language) that can read every claim.

#Why it matters

Knowing the expressiveness gap tells you where each provider's sharp edge is. On AWS the mistake is a wide sub. On GCP the mistake is a mapping that collapses distinct identities into one subject, or an attribute condition that was never written.

#How it works

AWS

GCP

In practiceThe GCP provider definition that enforces the same policy as the safe AWS example above, with the mapping and the condition both visible:

$ gcloud iam workload-identity-pools providers describe github --location=global --workload-identity-pool=ci --format=yaml
attributeCondition: assertion.repository_owner_id == "65" && assertion.repository_id == "74213" && assertion.job_workflow_ref == "acme/app/.github/workflows/deploy.yml@refs/heads/main"   ← rejected before IAM if false
attributeMapping:
  google.subject: assertion.repository_id + ":" + assertion.ref        ← short, stable, under 127 chars
  attribute.repository_id: assertion.repository_id
  attribute.environment: assertion.environment
oidc:
  allowedAudiences:
  - //iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/ci/providers/github   ← default aud; tokens for anything else fail
  issuerUri: https://token.actions.githubusercontent.com

🎯

On the job. On GCP, a provider with no attributeCondition accepts every token the issuer signs; the only thing then standing between any GitHub repository and your project is which principalSet bindings exist. On AWS, read the trust policy, not the permissions policy, first: a perfectly scoped permissions policy on a role anyone can assume is still a breach.

#Securing Ephemeral Runners and Multi-Tenant CI

#What is this?

The token is minted inside the job, where every step, every third-party action and every dependency's install script runs. Protecting the exchange means protecting the environment that holds the token for its few minutes of life.

#Why it matters

Federation removes the stored secret, but it creates an ambient credential: in GitHub Actions, any process in a job with id-token: write can read two environment variables and mint a token. A malicious dependency does not need to steal anything from a vault; it asks the platform politely.

#How it works

Where the token can leak, and the control for each:

In practiceThe workflow shape that keeps dependencies and tokens in different jobs. The deploy job runs nothing but pinned first-party steps:

jobs:
  build:
    permissions: { contents: read, id-token: none }        # ← npm/pip/cargo run here; no token exists to steal
    steps: [ ... ]                                         # produces an artifact
  deploy:
    needs: build
    environment: prod                                      # ← sub becomes repo:…:environment:prod after reviewer approval
    permissions: { contents: read, id-token: write }
    steps:
      - uses: aws-actions/configure-aws-credentials@<full-sha>   # ← first step: exchange immediately
        with:
          role-to-assume: arn:aws:iam::123456789012:role/app-prod-deploy
          role-duration-seconds: 900                        # ← 15 minutes, the job needs 4
          role-session-name: gha-${{ github.run_id }}       # ← shows up in CloudTrail
      - uses: actions/download-artifact@<full-sha>
      - run: aws s3 sync ./dist s3://app-prod-site --delete   # ← no third-party code runs in this job

📰

Real incident — tj-actions/changed-files (CVE-2025-30066, 2025). Between 12 and 15 March 2025, a GitHub Action used by more than 23,000 repositories had its version tags retroactively pointed at a commit that dumped the runner worker's memory and printed the contents, double-base64 encoded, into the job log. Every secret and credential the job held was exposed to anyone who could read the logs, including public repositories' logs. The attackers got in through a compromised bot token, likely via an earlier compromise of another action. CISA added it to the Known Exploited Vulnerabilities list. The lesson for federation: a token exchanged early and expiring in minutes limited the damage in jobs that used OIDC; jobs with long-lived keys in secrets had to rotate everything. And nothing about OIDC helps if the step that dumps memory runs in the same job as the exchange.

🎯

On the job. For each workflow with id-token: write, list every uses: and every package manager invocation in that job. If anything third-party runs there, split the job. Then check whether pull_request_target appears anywhere in the repository with a checkout of github.event.pull_request.head.sha: that is the Ultralytics shape.

#Engineering a Custom Token Verifier

#What is this?

The same verification, but for your own services: an internal API gateway that lets CI runs fetch build caches, a sidecar that gates access to bare-metal rack management, a broker that issues SSH certificates or database credentials to jobs. You become the relying party.

#Why it matters

Cloud providers ship a hardened verifier. Yours starts as forty lines that pass the demo. The interview question is whether you know what the other hundred lines are for.

#How it works

Checklist for a production verifier, in the order the code should run:

In practiceThe request path through such a gateway, as a sequence, with the one step people forget (issuer selection before key fetch):

sequenceDiagram
  participant R as CI runner
  participant V as Verifier sidecar
  participant K as JWKS cache
  participant P as Policy table
  R->>V: Bearer <jwt>
  V->>V: Parse; read iss (untrusted)<br/>select issuer config by exact match
  V->>K: key(kid) for that issuer
  K-->>V: RSA public key (cached)
  V->>V: Verify RS256; check aud, exp, nbf, jti
  V->>P: Match claims → scope
  P-->>V: scope=push:cache/acme-app
  V-->>R: Short-lived scoped token<br/>bound to runner egress IP

🎯

On the job. Ask for the verifier's test file before its implementation. If the negative cases are not there, treat the verifier as unverified. Then check the logging: a verifier that logs the raw bearer token at debug level has turned your log pipeline into the credential store you were trying to eliminate.