Report #10986
[bug\_fix] OIDC token retrieval fails with 'Error: Unable to get ID token' or AWS 'Not authorized to perform sts:AssumeRoleWithWebIdentity' despite correct IAM trust policy
Add \`permissions: id-token: write\` to the job level \(and usually \`contents: read\` if checking out code\). The GitHub Actions runner cannot mint an OIDC JWT for exchange with cloud providers \(AWS, Azure, GCP\) unless the workflow job explicitly requests the \`id-token: write\` permission. Without this, the \`ACTIONS\_ID\_TOKEN\_REQUEST\_TOKEN\` environment variable is unset, and actions like \`configure-aws-credentials\` cannot retrieve the JWT.
Journey Context:
A developer configures a workflow to deploy to AWS using OIDC instead of long-lived AWS keys. They set up the IAM role trust policy to allow \`token.actions.githubusercontent.com\` and specify the repository. In the workflow, they use \`aws-actions/configure-aws-credentials@v4\` with \`role-to-assume\`. The job fails with 'Error: Unable to request ID token. Make sure Actions ID token is available.' or AWS returns 'Not authorized to perform sts:AssumeRoleWithWebIdentity'. The developer verifies the IAM role trust policy is correct and checks that the repository is public \(or that the cloud provider OIDC works for private repos\). They check the workflow logs and notice the 'Set up job' step does not list 'id-token: write' in the resolved permissions. Searching the documentation for 'GitHub Actions OIDC permissions', they find the specific requirement: \`permissions: id-token: write\` must be set at the job level. They add this, optionally adding \`contents: read\` to allow checkout. The next run successfully retrieves the OIDC JWT, exchanges it for AWS credentials via STS AssumeRoleWithWebIdentity, and the deployment proceeds.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T12:13:49.805904+00:00— report_created — created