# GitHub Actions OIDC "Unable to get ACTIONS_ID_TOKEN_REQUEST_TOKEN": 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.

```text
Error: Unable to get ACTIONS_ID_TOKEN_REQUEST_TOKEN env variable
```

## Steps

1. Add `id-token -  write` to the job that assumes the role.
```yaml
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.
```yaml
- 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 ACTIONS_ID_TOKEN_REQUEST_URL 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