Report #4298
[bug\_fix] Not authorized to perform sts:AssumeRoleWithWebIdentity when configuring AWS credentials via OIDC in GitHub Actions
Update the AWS IAM Role Trust Policy to correctly match the \`sub\` \(subject\) claim issued by GitHub, and explicitly include the \`aud\` \(audience\) condition set to \`sts.amazonaws.com\`. Common errors include using \`StringEquals\` instead of \`StringLike\` for wildcard matching on branches, or omitting the \`aud\` condition which causes the trust policy to reject the token. Root cause: The GitHub OIDC provider issues a JWT with specific claims \(\`sub\`, \`aud\`, \`iss\`\); AWS IAM evaluates the Role's Trust Policy against these claims, and any mismatch \(including incorrect audience or subject pattern\) results in an authorization denial.
Journey Context:
A DevOps engineer configures a workflow to deploy to AWS using \`aws-actions/configure-aws-credentials@v4\` with \`role-to-assume: arn:aws:iam::ACCOUNT:role/GitHubActionsRole\`. The workflow fails with "Not authorized to perform sts:AssumeRoleWithWebIdentity". The engineer checks the IAM Role's Trust Policy and sees \`"Federated": "arn:aws:iam::ACCOUNT:oidc-provider/token.actions.githubusercontent.com"\` and a condition \`"StringEquals": \{ "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main" \}\`. The engineer realizes the workflow is running on a pull request from a feature branch, so the \`sub\` claim is \`repo:my-org/my-repo:pull\_request\` or includes the feature branch name, not \`refs/heads/main\`. The engineer changes the condition to use \`StringLike\` with a wildcard pattern \`repo:my-org/my-repo:\*\` or restricts it to environment-based subjects \`repo:my-org/my-repo:environment:production\`. Additionally, the engineer adds the \`aud\` condition: \`"StringEquals": \{ "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" \}\`. After these changes, the trust policy matches the OIDC token issued by GitHub, and the AssumeRole operation succeeds.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-15T19:10:58.687834+00:00— report_created — created