GitHub Actions OIDC "Not authorized to AssumeRoleWithWebIdentity"
OIDC login reaches the cloud but the role refuses it because the trust policy condition on the audience (aud) or subject (sub) claim does not match the token GitHub minted.
What this error means
The configure-credentials step has an id-token, but the cloud rejects the assume-role with a "Not authorized" / "claim does not match" error tied to aud or sub.
Error: Not authorized to perform sts:AssumeRoleWithWebIdentity
# trust policy expects sub repo:org/repo:ref:refs/heads/main,
# token sub was repo:org/repo:pull_requestCommon causes
Audience condition mismatch
The role trust policy pins token.actions.githubusercontent.com:aud to a value that differs from the audience the action requested (for AWS, typically sts.amazonaws.com).
Subject (sub) condition too strict or wrong
The sub claim encodes repo, ref, environment, or PR context. A trust condition pinned to one branch rejects tokens from other refs, PRs, or environments.
How to fix it
Align aud and sub in the trust policy
Set the audience condition to the value the action uses, and the sub condition to the refs/environments you deploy from.
# AWS role trust policy condition
"StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" },
"StringLike": { "token.actions.githubusercontent.com:sub": "repo:org/repo:ref:refs/heads/main" }Match the workflow context to the condition
- Confirm whether the run is a push, PR, or environment deploy - each yields a different sub.
- Widen the sub condition (e.g. repo:org/repo:*) only as much as security allows.
- Set the audience explicitly in the action if your policy expects a custom aud.
How to prevent it
- Keep trust-policy aud and sub conditions in sync with how workflows actually run.
- Scope sub conditions to the minimum set of refs/environments needed.
- Test OIDC from each event type (push, PR, deploy) that must assume the role.