Accessdenied Not Authorized To Perform STS AssumeRoleWithWebIdentity | Fix Role Trust And Tokens

Hitting the accessdenied not authorized to perform sts assumerolewithwebidentity message can freeze a whole deployment, even when everything looks correct in the console.
This guide breaks the error into small, repeatable checks so you can see why AWS Security Token Service (STS) refused the call and what to change in IAM, trust policy, or identity tokens to clear it.

What This STS AssumeRoleWithWebIdentity Error Means

STS AssumeRoleWithWebIdentity lets an application swap a web identity token from a provider such as Amazon Cognito, an OpenID Connect (OIDC) issuer, or a Kubernetes OIDC endpoint for temporary AWS credentials.
The client sends the token and target role ARN, STS validates both against IAM configuration, and returns short-lived credentials when the check passes.

When you see the full string AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity with HTTP status code 403, STS accepted the request format but rejected the operation.
That rejection usually means one of three things: the IAM trust policy does not allow the caller, the caller lacks permission to call STS on that role, or the web identity token does not match the role’s conditions.

AWS treats this as a hard deny.
No temporary credentials are issued, so any downstream calls to services like S3, DynamoDB, or Route 53 that depend on this role never even start.
Fixing the source of the deny in IAM or identity configuration is the only way through; retries will keep failing until those settings line up.

Before changing code, it helps to view this error as a simple question: who is trying to act, which role are they asking for, and what does IAM say about that combination?
Each of the next sections answers one part of that question with concrete checks.

Common Setups That Trigger Accessdenied Not Authorized To Perform STS AssumeRoleWithWebIdentity

The same error appears across a range of workloads, which can make it feel random.
In practice, similar patterns repeat across a few standard setups where web identity tokens drive access.

• Cognito User Pools To AWS Services — Web or mobile apps log users in with Cognito, then call STS through the AWS SDK to assume an IAM role that writes to S3, DynamoDB, or other services.
• EKS IAM Roles For Service Accounts (IRSA) — Pods use a Kubernetes service account annotated with a role ARN. The cluster OIDC provider issues tokens, and STS trades them for role credentials.
• GitHub Actions And Other OIDC Workflows — Pipelines use an external OIDC provider to request an AWS role, so builds can deploy or run tests without long-lived keys.
• Custom OIDC Providers — An in-house identity service or third-party OIDC issuer feeds tokens to STS so line-of-business apps can access AWS resources directly.

Across these setups, breaking changes tend to fall into the same buckets: a role trust policy that names the wrong identity provider, an aud or sub claim mismatch, or a caller that no longer has permission to call sts:AssumeRoleWithWebIdentity.
Small edits, such as renaming a Kubernetes service account or rotating an OIDC issuer URL, can introduce this error even when policy JSON looks tidy at a glance.

That is why a clear checklist helps.
Instead of guessing at random settings, you walk from the error text to the role, then to the identity token, then to the exact allow statements that need a change.

Fixing The STS AssumeRoleWithWebIdentity Accessdenied Error Step By Step

Rather than changing several things at once, move through a steady sequence.
Each step narrows the cause and keeps your fixes safe, especially in shared accounts.

Root Cause	Where To Check	Typical Fix
Role trust does not match identity provider or claims	IAM role trust policy	Update Principal.Federated and Condition with correct provider ARN and token claims
Caller cannot invoke STS on that role	Caller policies (user, role, or service account-linked role)	Add an allow statement for sts:AssumeRoleWithWebIdentity on the role ARN
Wrong role ARN or expired or wrong-audience token	Application configuration and identity provider	Fix ARN in code or config, verify token aud, sub, and expiration

• Start From The Exact Error Message — Capture the full text, including the request ID and any role ARN that appears. This anchors the rest of your checks to a single failing call.
• Confirm Which Role Is Failing — Match the ARN in logs or SDK configuration to one IAM role in the console. Mis-typed ARNs and deleted roles are more common than they appear.
• Check The Caller Identity — Work out who is actually calling STS. In EKS, that is the pod’s IAM role for service account; with Cognito, it is the web identity principal that fronts your app.

Once you have the role, the caller, and the token source lined up on paper, the rest of the work turns into small edits in IAM and the identity provider.
The next sections walk through those edits in more detail.

Checking IAM Role Trust Policy And Permissions

The trust policy on the target role decides which identities may ask for temporary credentials.
If this policy does not mention your OIDC provider, or its conditions filter out your token’s claims, STS responds with access denied even if attached permissions policies look fine.

• Open The Role And Inspect Trust — In the IAM console, choose the role named in the error, switch to the trust relationship tab, and read through the JSON document from top to bottom.
• Validate The Federated Principal — The Principal.Federated field must match the ARN of your OIDC provider, such as the EKS OIDC issuer or the Cognito identity pool provider.
• Review Action And Effect — Ensure the statement for your provider has "Action": "sts:AssumeRoleWithWebIdentity" and "Effect": "Allow", with no overlapping deny statement that cancels it.

A typical trust statement for an EKS service account looks similar to this snippet:

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.region.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "oidc.eks.region.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:sub":
        "system:serviceaccount:namespace:service-account-name",
      "oidc.eks.region.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:aud":
        "sts.amazonaws.com"
    }
  }
}

In EKS, the sub claim joins the namespace and service account name.
A mismatch here, even a single character, prevents the pod token from passing the trust policy filter.
The same applies to the audience claim: if your provider issues a different aud, the string check fails.

• Align Conditions With Real Claims — Compare the Condition block with an actual decoded token and adjust any StringEquals keys or values that no longer match.
• Watch For Multiple Statements — If the role has several trust statements, make sure the one for your provider is not overshadowed by a deny or by a statement that narrows the principal in a way that excludes your caller.
• Grant STS Permission To The Caller — Attach or update a policy on the caller identity so it has an allow line for sts:AssumeRoleWithWebIdentity on the target role ARN.

At this point you have covered the IAM side.
If the error still appears, the remaining suspects are the token itself or the wiring between your code and the identity provider.

Verifying Web Identity Tokens And Callers

The token that reaches STS carries the claims your trust policy checks.
If those claims differ from what you expect, or the token expires before STS receives it, the request fails and accessdenied not authorized to perform sts assumerolewithwebidentity appears again.

• Decode A Real Token — Capture one failing call, copy the JWT from logs or debugging output, and decode it with a local tool to view headers and claims in plain JSON.
• Confirm Issuer And Audience — Match the iss claim to the OIDC provider you registered in IAM and compare the aud claim with the values in your trust policy conditions.
• Check Subject And Session Details — In EKS, confirm the sub claim uses the namespace and service account name that you tied to the role. For Cognito or other providers, confirm user pool or client identifiers match the accounts in your design.

Time values also matter.
If the token lifetime is short and your application caches it for too long, STS may see an expired token even though the rest of the request looks right.
Adjusting either the cache or the identity provider session length stops this failure mode.

• Align SDK Configuration With The Role — Check that your SDK or application configuration points at the same role ARN you inspected in IAM, with the correct region and account.
• Test With A Minimal Script — Use the AWS CLI or a tiny SDK snippet that calls AssumeRoleWithWebIdentity directly with a known token, which isolates IAM and token issues from application logic.

When a minimal script can assume the role but the main app cannot, the gap usually lies in how tokens are fetched or refreshed in that app.
When both fail, the problem sits in IAM, the identity provider configuration, or the way the provider issues claims for this client.

Final Checks To Keep This STS Error Away

Once the immediate outage is fixed, a few closing checks help stop the same accessdenied string from returning during the next release or cluster change.
These checks are simple and fit easily into normal review habits.

• Document Role And Identity Links — Record which roles map to which service accounts, user pools, or OIDC clients so teammates can update both sides together.
• Pin And Monitor OIDC Provider Settings — Track issuer URLs and thumbprints for your providers, since changes there can break trust policies even when IAM roles stay the same.
• Add A Quick STS Health Test — Include a lightweight AssumeRoleWithWebIdentity call in your deployment checks, so this error appears in pipelines instead of only under live load.
• Review Permissions During Refactors — When roles, namespaces, or identity pool names change, adjust both trust policies and caller policies in the same pull request.

The full string AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity looks severe at first, yet it always comes back to a small set of facts: which role you picked, which identity token you passed in, and what IAM currently promises about that pair.
When you line up those three details, the error clears and the same pattern works across Cognito, EKS, GitHub Actions, and any other OIDC-driven workload that depends on STS.