Fixing “Not authorized to perform sts:AssumeRoleWithWebIdentity” in GitHub Actions

This error comes from AWS STS. The job got a token from GitHub, aws-actions/configure-aws-credentials presented it, and the role’s trust policy did not allow it. Something in the token’s claims differs from what the policy compares against. Work down this list in order.

1. Is the repository sending the immutable sub format?

Repositories created, renamed or transferred after July 15, 2026 send repo:OWNER@OWNER_ID/REPO@REPO_ID:… instead of repo:OWNER/REPO:….[GitHub Changelog] A policy written for the old format will not match, even with a wildcard after the repository name, because the IDs sit in the middle of the string. AWS’s action README lists this as a cause of this exact error.[AWS (GitHub repository)]

Fix: add the immutable value, or check repository_id and repository_owner_id as separate condition keys. Details in the immutable subject guide.

2. Does the job context match the sub you wrote?

GitHub builds the second half of sub from the job, and the rules are easy to misread:[GitHub Docs]

Job	sub ends with
Job that names an environment:	:environment:NAME (no branch at all)
Job triggered by pull_request, no environment	:pull_request
Push to a branch, no environment	:ref:refs/heads/BRANCH
Push to a tag, no environment	:ref:refs/tags/TAG

Common traps:

• Adding environment: production to a deploy job changes its subject. A policy pinned to ref:refs/heads/main stops matching.
• A pull request job never sends the branch name in sub.
• Colons inside values are sent as %3A, so an environment called prod:us appears as environment:prod%3Aus.

3. Is there a wildcard under StringEquals?

StringEquals compares text literally. In "repo:octo-org/octo-repo:*" the asterisk only matches a real asterisk, so no token will ever match. Use StringLike for patterns, where * matches any run of characters and ? matches one.

4. Does the audience match?

The action requests the audience sts.amazonaws.com unless you set its audience input. GitHub’s and AWS’s examples check token.actions.githubusercontent.com:aud against that value.[GitHub Docs][AWS (GitHub repository)] If you set a custom audience in the workflow, the policy must expect the same string. AWS maps the aud condition key to the token’s azp claim when one is present and to aud otherwise.[AWS IAM User Guide]

5. Does the Principal point at the right provider?

The Federated principal must be the ARN of the GitHub OIDC provider in the same account as the role:

arn:aws:iam::ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com

Check that the provider exists in that account (IAM → Identity providers) and that the account ID in the ARN is right. Copying a policy between accounts without changing it is a frequent cause.

6. Has someone customized the subject claim?

Organization or repository admins can replace the default sub with a custom template through GitHub’s REST API (include_claim_keys). The customized subject replaces the default format entirely, for example repo:ORG/REPO:environment:prod:job_workflow_ref:….[GitHub Docs] If a template was applied, every trust policy for those repositories must use it. GitHub warns that tokens may be rejected if the cloud side is not updated first.

7. Does the workflow have permission to request a token?

The job (or workflow) needs:

permissions:
  id-token: write
  contents: read

Without id-token: write the job cannot request a token from GitHub at all.[GitHub Docs] In that case the failure happens before STS is called, so it usually shows a different message. Check it anyway if the job’s permissions block was recently changed.

After it works, tighten it

A policy that finally matches is not necessarily a safe policy. Run it through the checker again and look at the warnings: trust on names only, any branch allowed, no audience check. IAM refuses new GitHub trust policies that have no sub condition, but older roles may predate that check.[AWS IAM User Guide] The AWS trust policy guide covers scoping in detail.