GitHub Actions OIDC "Not authorized to perform sts:AssumeRoleWithWebIdentity"
AWS rejects the OIDC token when the role trust policy condition (the sub or aud claim) does not match the repository, branch, environment, or audience presented by the workflow. This is a configuration mismatch, not a transient failure.
What this error means
The configure-aws-credentials step authenticates to GitHub but STS denies the role assumption with an access-denied error referencing the web identity.
Error: Could not assume role with OIDC: Not authorized to perform sts:AssumeRoleWithWebIdentity
(AccessDenied) for role arn:aws:iam::123456789012:role/gha-deployCommon causes
sub claim condition does not match
The trust policy StringLike on token.actions.githubusercontent.com:sub does not include the repo:owner/repo:ref or environment your job runs under.
Wrong or missing audience
The aud condition expects sts.amazonaws.com but the action requested a different audience, or vice versa.
How to fix it
Align the trust policy sub condition
- Print the actual subject by enabling debug, or derive it: repo:OWNER/REPO:ref:refs/heads/main, or repo:OWNER/REPO:environment:production.
- Update the role trust policy StringLike condition to match (wildcards allowed for multiple refs).
- Confirm the aud condition is sts.amazonaws.com (the configure-aws-credentials default).
{
"Effect": "Allow",
"Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" },
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" },
"StringLike": { "token.actions.githubusercontent.com:sub": "repo:OWNER/REPO:*" }
}
}How to prevent it
- Scope the sub condition as tightly as your deploy model allows (branch or environment), not just the repo.
- Document the expected subject format next to the role definition so it stays in sync with workflow changes.