Skip to content
Latchkey

OIDC token environment claim scope mismatch in CI

When a job sets environment:, GitHub changes the OIDC token sub to repo:owner/repo:environment:<name> instead of a ref form. A trust policy written for a branch sub then no longer matches and the cloud login is denied.

What this error means

OIDC login works on branch builds but fails once the job adds an environment: key, with a "not authorized" or "no matching federated identity" denial keyed to an environment subject.

.github/workflows/ci.yml
# job adds: environment: production
# token sub becomes:
repo:my-org/my-repo:environment:production
# but trust policy expects:
repo:my-org/my-repo:ref:refs/heads/main

Common causes

The job declares an environment

Adding environment: switches the sub to the environment form, so any condition keyed to a ref no longer matches.

The cloud trust condition only allows the ref form

The IAM/WIF/federated credential subject lists a branch sub and has no entry for the environment subject.

How to fix it

Add the environment subject to the trust condition

  1. Decide whether jobs use environment:; if so, expect the environment sub.
  2. Add a condition entry for repo:owner/repo:environment:<name>.
  3. Re-run the environment-scoped job.
Trust condition
"token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:environment:production"

Customize the subject claim if you need a single form

Repository OIDC settings can include or exclude the environment claim to keep a stable subject shape.

Repository settings
# Settings > Actions > General > OIDC subject claim template
# choose which claims (ref, environment) appear in sub

How to prevent it

  • Account for the environment: form of sub in cloud trust conditions.
  • Use a consistent subject claim template across repos.
  • Add separate trust entries for ref and environment subjects.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →