GitHub Actions OIDC "Unable to get ACTIONS_ID_TOKEN_REQUEST_TOKEN": AWS auth fix
Fixes GitHub Actions OIDC failures where aws-actions/configure-aws-credentials errors with 'Unable to get ACTIONS_ID_TOKEN_REQUEST_TOKEN'. Use when a workflow job assumes an AWS IAM role via OIDC and the token env vars are missing; adding id-token - write permissions resolves it. Not for static access-key auth, IAM AccessDenied errors, or GitHub Enterprise Server versions without OIDC support.
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 variableSteps
- Add
id-token - writeto the job that assumes the role.
jobs:
deploy:
permissions:
id-token - write
contents: readExpected: The next run gets past credential configuration instead of failing immediately.
- Check that nothing in the workflow overrides the token env vars. Search the YAML for
ACTIONS_ID_TOKEN_REQUEST_TOKENorACTIONS_ID_TOKEN_REQUEST_URLappearing in anyenv:block.
Expected: No hits. If a step sets one of these to an empty value, it shadows what the runner provides. Delete the override.
- Confirm the step actually uses OIDC. The
configure-aws-credentialsstep must passrole-to-assumeand 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-2Expected: The step log shows it requesting an OIDC token rather than complaining about missing env vars.
- 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.
- 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 ownid-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_TOKENorUnable 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
AccessDeniedorInvalidIdentityToken. 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-levelpermissions: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
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.