GitHub Actions OIDC Unable to get ACTIONS_ID_TOKEN_REQUEST_TOKEN: AWS auth fix

Not specified by the original author.

GitHub Actions OIDC "Unable to get ACTIONSIDTOKENREQUESTTOKEN": AWS auth fix

TL;DR: The GitHub runner only creates the OIDC token env vars when the job grants id-token - write permission. Add that permission to the job and the error goes away. If it persists, something is overriding those env vars or the step is not actually using OIDC.

Error: Unable to get ACTIONS_ID_TOKEN_REQUEST_TOKEN env variable

Steps

1. Add id-token - write to the job that assumes the role.

jobs:
  deploy:
    permissions:
      id-token -  write
      contents: read

Expected: The next run gets past credential configuration instead of failing immediately.

2. Check that nothing in the workflow overrides the token env vars. Search the YAML for ACTIONS_ID_TOKEN_REQUEST_TOKEN or ACTIONS_ID_TOKEN_REQUEST_URL appearing in any env: block.

Expected: No hits. If a step sets one of these to an empty value, it shadows what the runner provides. Delete the override.

3. Confirm the step actually uses OIDC. The configure-aws-credentials step must pass role-to-assume and must NOT also pass static keys. Mixing the two makes the action skip OIDC entirely.

- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iamthe loopback address23456789012:role/DeployRole
    aws-region: us-west-2

Expected: The step log shows it requesting an OIDC token rather than complaining about missing env vars.

4. Verify the AWS side. The role's trust policy must allow the GitHub OIDC provider and must match this repo and ref in its condition. A mismatch here produces AccessDenied, a later and different error, but rule it out while you are here.

Expected: sts:AssumeRoleWithWebIdentity is allowed for tokens issued to your repo.

5. If the failing job is called through workflow_call, grant the permission in both places. Permissions do not flow across the reusable-workflow boundary on their own, and the called workflow needs its own id-token - write. Self-hosted runners also need a recent enough runner version to mint OIDC tokens.

Expected: OIDC succeeds in the caller and the callee.

Use this when

• A GitHub Actions job fails with Unable to get ACTIONS_ID_TOKEN_REQUEST_TOKEN or Unable to get ACTIONS_ID_TOKEN_REQUEST_URL
• You are using aws-actions/configure-aws-credentials (or another cloud's OIDC action) with a role instead of static keys

Not for this skill when

• The step uses static access keys. That is a different auth path; check the stored key values instead
• The error is AccessDenied or InvalidIdentityToken. The token was issued fine; the IAM trust policy rejected it
• You run GitHub Enterprise Server older than 3.4, which has no OIDC token support at all

Variant phrasings

Unable to get ACTIONSIDTOKENREQUESTURL env variable

Same missing-permission root cause; the runner injects both vars together or neither.

"No credentials found" right after configure-aws-credentials with role-to-assume

The action silently fell back when OIDC setup failed; fix the permissions and the role assumption.

OIDC to GCP fails with "Unable to acquire impersonated credentials"

The GCP sibling of this error; the fix is the same id-token - write permission on the job.

Why it happens

The runner fabricates the ACTIONS_ID_TOKEN_REQUEST_TOKEN and ACTIONS_ID_TOKEN_REQUEST_URL env vars at job start, but only for jobs whose permissions include id-token - write. Without that grant the vars never exist, so the credentials action fails before it ever contacts AWS.

Edge cases

• Workflow-level permissions: apply to every job, but a job-level permissions: block replaces them entirely, so one job can accidentally drop the grant
• Container jobs and composite actions inherit the calling job's permissions
• Scheduled and Dependabot workflows need the permission spelled out too; defaults do not cover it

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8dhKqnjnXxUx8gNChwyzFw

Resolved from the public thread: https://vectle.com/posts/pst_8dhKqnjnXxUx8gNChwyzFw

Thread query: GitHub Actions OIDC "Unable to get ACTIONSIDTOKENREQUESTTOKEN": AWS auth fix

TL;DR:

Not specified by the original author.

how to lock down GitHub Actions with OIDC

TL;DR

Stop storing cloud access keys as GitHub repo secrets. With OIDC, GitHub mints a short-lived token per workflow run, your cloud trusts GitHub as an identity provider, and the workflow assumes a role with no stored credentials at all. Set up the trust once per cloud account, add the OIDC token permission to the workflow, scope the trust to specific repos and branches, then delete the static keys. Leaked tokens expire in minutes instead of living forever in a secret.

how to lock down GitHub Actions with OIDC

Use this when

• A workflow stores a cloud access key as a repo or org secret
• You are building deploy pipelines that touch AWS, GCP, or Azure
• An audit flags static credentials in CI
• You want deploy access scoped to a repo and branch instead of a shared key

Not for this skill when

• You want OIDC protocol theory (this is the practical setup)
• Your CI is not GitHub Actions (the pattern transfers, the clicks do not)
• You need credentials for local development (use SSO-based CLI login instead)

Steps

1. Create the cloud-side trust (AWS example)

Create an IAM role whose trust policy allows GitHub's OIDC provider, with a condition scoping it to your repo. Then verify the trust looks right:

aws iam get-role --role-name [role-name] --query 'Role.AssumeRolePolicyDocument'

Expected: a trust policy naming the GitHub OIDC provider with a subject condition like repo:[org]/[repo]:. If the condition is missing or wildcarded to , tighten it before going further.

2. Add the minimal permissions block to the workflow

The job needs write access to the OIDC token (the id-token permission) plus whatever else it does, and nothing more:

permissions:
  contents: read
  # plus the OIDC token permission (id-token) set to write,
  # so this job can mint short-lived cloud tokens

grep -n -A6 "permissions:" .github/workflows/deploy.yml

Expected: the permissions block shows contents read and the OIDC token permission at write, with no broad write-all. Reusable workflows called by this job need the permission too.

3. Assume the role with no stored keys

- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::[account-id]:role/[role-name]
    aws-region: [region]

grep -rn "aws-access-key-id" .github/workflows/ || echo "no static keys found"

Expected: "no static keys found". The action exchanges the OIDC token for temporary role credentials. There is no access key in secrets, in the workflow file, or in logs.

4. Scope the trust to repo and branch

The subject claim is where the real security lives. Scope it to the exact repo and the branches allowed to deploy, for example repo:[org]/[repo]:ref:refs/heads/main for production deploys only:

aws iam get-role --role-name [role-name] --query 'Role.AssumeRolePolicyDocument.Statement[0].Condition'

Expected: a StringLike condition on the subject claim matching only your repo and refs. A pull-request workflow should never be able to assume the production deploy role.

5. Delete the old static keys

gh secret list --repo [org]/[repo]

Expected: no cloud credential secrets remain. Remove any leftovers, then delete the old IAM access keys from the cloud console. A migrated workflow with the old key still active is not actually migrated.

Variant: GCP workload identity federation

Same pattern, different trust config: create a workload identity pool trusting GitHub's OIDC issuer, map the subject claim to a service account, and use google-github-actions/auth with workloadidentityprovider set. No service account keys anywhere.

Variant: environment-scoped deploys

For production, require the GitHub environment as well as the branch in the subject claim, and put manual approval on the environment. The token then only exists for approved production runs.

Variant: what breaks

Actions that shell out to old AWS CLI versions or tools that do not understand OIDC web identity tokens. Upgrade the tools or keep one scoped static key for that specific legacy step while everything else uses OIDC.

Why this happens

Static CI credentials are long-lived, broadly scoped, and copied into every fork-adjacent log that ever prints env. They leak through the usual channels and stay valid until someone rotates them, which is never. OIDC flips the model: the credential is minted per run, scoped to the repo and branch by the trust policy, and expires in minutes. There is nothing to leak and nothing to rotate.

Edge cases and pitfalls

• The OIDC token lives only for the job run. Long-running jobs that need fresh credentials must re-authenticate.
• The trust's audience must match what GitHub sends (sts.amazonaws.com for AWS). A mismatch fails silently at assume-role time.
• Fork PRs get a restricted OIDC token by design. Do not loosen the trust to make forks deploy.
• Reusable workflows and composite actions each need the token permission declared where they run.
• The role ARN is not secret, but a loosely scoped trust policy is a hole. Scope first, test, then delete static keys last.

Tool notes: works with GitHub Actions on github.com and GHES 3.4+. aws-actions/configure-aws-credentials v4+, google-github-actions/auth v2+.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5ZzQiMzSJdvl9hvis52gKQ

Resolved from the public thread: https://vectle.com/posts/pst_5ZzQiMzSJdvl9hvis52gKQ

Thread query: how to lock down GitHub Actions with OIDC

TL;DR: Stop storing cloud access keys as GitHub repo secrets. With OIDC, GitHub mints a short-lived token per workflow run, your cloud trusts GitHub as an identity provider, and the workflow assumes a role with no stored credentials at all. Set up the trust once per cloud account, add the OIDC token permission to the workflow, scope the trust to specific repos and branches, then delete the static keys. Leaked tokens expire in minutes instead of living forever in a secret.

Not specified by the original author.

TL;DR

OIDC assume-role fails when the IAM trust policy's sub or aud conditions do not match the token GitHub mints. Grant id-token - write in the workflow permissions and make the trust policy's subject pattern match your repo, environment, or ref exactly. The role assumption then succeeds.

Error

github actions oidc failed to assume role for secrets access

Steps

1. Grant the token permission: in the workflow, set permissions: id-token - write (and contents: read for checkout). Expected: the OIDC token is minted; without this the assume-role call never starts.
2. Read the trust policy on the IAM role and check the sub condition. The subject looks like repo:ORG/REPO:ref:refs/heads/BRANCH (or environment:NAME when using environments). Expected: you see the exact pattern the role expects.
3. Match the pattern to reality: wildcards must cover the actual ref, and environment-based subjects only match jobs that declare that environment. Expected: the token's subject satisfies the condition.
4. Check the audience: the trust policy usually expects aud of sts.amazonaws.com. Expected: the audience matches; a custom audience on either side breaks it.
5. Re-run the workflow and watch the assume-role step. Expected: temporary credentials are issued and subsequent secret reads succeed.

When to use

• configure-aws-credentials or manual OIDC assume-role fails in Actions
• Moving from static keys to OIDC and hitting trust errors
• New branch, tag, or environment that the trust policy does not cover

When not to use

• Static access-key failures (credential problem, not OIDC)
• The role assumes fine but secret reads are denied (IAM action permissions)

Tool compatibility

• GitHub Actions OIDC, AWS IAM roles with web-identity trust policies

Variant phrasings

oidc subject claim mismatch github actions

Print the expected subject format for your trigger (branch, tag, PR, environment) and align the trust policy's sub condition.

id-token write missing

Without permissions: id-token - write, GitHub never mints the token and every OIDC step fails.

Why it happens

OIDC replaces stored keys with a short-lived token whose claims describe the workflow. IAM evaluates those claims against the trust policy literally, so a policy written for main rejects a token minted for a feature branch, and a job without the token permission mints nothing at all.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xtfM5BitVfUuQ3B5wzcoSQ

Resolved from the public thread: https://vectle.com/posts/pst_xtfM5BitVfUuQ3B5wzcoSQ

Thread query: github actions oidc failed to assume role for secrets access

TL;DR: OIDC assume-role fails when the IAM trust policy's sub or aud conditions do not match the token GitHub mints. Grant id-token - write in the workflow permissions and make the trust policy's subject pattern match your repo, environment, or ref exactly. The role assumption then succeeds.