github actions oidc failed to assume role for secrets access

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.

Not specified by the original author.

TL;DR

Delete the static cloud secrets this replaces. OIDC federation removes the key - the workflow proves its identity to the cloud provider at runtime and receives a credential that lives only as long as the run. You register that provider on the cloud side with a trust policy pinned to your repo, and the workflow exchanges its identity for short-lived cloud credentials.

When to use

You are seeing this: GitHub acts as an OIDC identity provider for your workflows. Use this skill when you run into "GitHub Actions to cloud without stored secrets: OIDC federation".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

The shape of the fix

GitHub acts as an OIDC identity provider for your workflows. You register that provider on the cloud side with a trust policy pinned to your repo, and the workflow exchanges its identity for short-lived cloud credentials. Nothing static is stored anywhere.

Steps

1. In the workflow job, set permissions: contents read, plus write on the token-request scope (the id-token key in the permissions block). Without that, GitHub will not mint the identity token for the run.
2. On the cloud side, add GitHub as an OIDC provider (the provider URL is in the doc linked below) and write a trust policy that matches only your repo, ideally pinned further to a branch or environment. A trust policy matching the whole org is barely better than a shared key.
3. In the workflow, call the cloud's login action with the role to assume. No static credentials in secrets at all.
4. Delete the static cloud secrets this replaces. A leftover key is a backdoor.

Checks

• Grep the org for long-lived cloud keys in Actions secrets. Each one is a candidate for federation.
• If a workflow genuinely cannot use OIDC, write down why, and give that secret the narrowest scope and shortest life possible.

Why stored cloud keys are the wrong default

A long-lived cloud access key in GitHub Secrets works fine until it leaks. Then it works for whoever took it, from anywhere, until someone notices and rotates it. OIDC federation removes the key - the workflow proves its identity to the cloud provider at runtime and receives a credential that lives only as long as the run.

GitHub's docs describe using OpenID Connect within workflows to authenticate with cloud providers, with the workflow requesting an identity token via the token-request permission and trust configured on the cloud provider side. Source: https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers

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: