Call the API

The payoff is deliberately boring. The Storage API neither knows nor cares that this credential began life as a Forgejo OIDC assertion — it sees ci-deployer@authlab-lab.iam.gserviceaccount.com and evaluates its IAM roles like any other caller. The API never saw the OIDC token.

what actually happens

The runner calls the Storage API with the SA access token as an ordinary Bearer credential.
GCP authorizes the SA — role evaluation on ci-deployer@authlab-lab.iam.gserviceaccount.com; federation plays no part here.

input · from step 3

sa access token ya29.c.SYNTHETIC-sa-access-token-not-valid-for-use minted in step 3 →

Call sequence

A plain authorized API call — the point is that nothing about it is special anymore.

step 2 · Storage API returns · 200

{
  "kind": "storage#buckets",
  "items": [
    {
      "kind": "storage#bucket",
      "name": "authlab-lab-artifacts",
      "projectNumber": "1234567890",
      "location": "US",
      "storageClass": "STANDARD"
    }
  ]
}

bucket authlab-lab-artifacts · US · STANDARD

Who GCP sees

The resolved identity at the end of the chain — a concrete service account, nothing federated about it.

ci-deployer@authlab-lab.iam.gserviceaccount.com roles evaluated: storage.buckets.list

The chain, end to end

Four artifacts, each traded for the next. Only the first one ever contained the workload's story.

1 oidc jwt signed assertion from Forgejo
2 federated token GCP recognizes the identity
3 sa access token concrete SA credential
4 api response ordinary authorized call

Compare with the workforce track, where the same class of token meets a very different validator.