How Can I Fix the Not Authorized To Perform Sts Assumerolewithwebidentity Error?
Encountering the error message “Not Authorized To Perform Sts Assumerolewithwebidentity” can be a frustrating roadblock for developers and cloud engineers working with AWS Identity and Access Management (IAM) and Security Token Service (STS). This issue often surfaces when attempting to assume a role using web identity federation, a critical process for enabling secure, temporary access to AWS resources via external identity providers like Google, Facebook, or Amazon Cognito. Understanding why this authorization failure occurs is essential for maintaining seamless authentication flows and robust security in cloud environments.
At its core, the error signals a permissions or configuration mismatch that prevents the STS from granting the requested temporary credentials. It highlights the intricate interplay between IAM roles, trust policies, and the permissions granted to the calling entity. While the message itself is straightforward, the underlying causes can range from misconfigured trust relationships to insufficient permissions or incorrect identity provider setups.
This article will guide you through the foundational concepts behind the “Not Authorized To Perform Sts Assumerolewithwebidentity” error, helping you grasp the mechanisms of role assumption via web identity. By gaining a clear overview of the common pitfalls and the AWS security model involved, you’ll be better equipped to diagnose and resolve this issue efficiently, ensuring your applications maintain secure
Common Causes of the Not Authorized Error
The “Not Authorized To Perform Sts Assumerolewithwebidentity” error typically arises due to misconfigurations or missing permissions when attempting to assume an AWS IAM role via the Security Token Service (STS) using a web identity token. Understanding the root causes can significantly streamline troubleshooting.
One frequent cause is the absence of the necessary trust relationship between the IAM role and the identity provider. The role must explicitly trust the web identity provider (such as Amazon Cognito, Google, or Facebook) to allow the STS AssumeRoleWithWebIdentity call. Without this trust policy, AWS denies the request.
Another common issue is insufficient permissions attached to the user or service attempting the assume role action. The caller’s IAM policy must grant the `sts:AssumeRoleWithWebIdentity` permission for the specific role ARN. If this permission is missing or restricted, the operation will fail.
Additionally, the web identity token itself may be invalid or expired, which can cause the authorization failure. The token must be valid, unexpired, and issued by a trusted provider recognized by the role’s trust policy.
Other causes include:
- Incorrect or malformed role ARN specified in the assume role request
- Mismatch between the audience (`aud`) claim in the token and the expected value in the trust policy
- Use of temporary credentials that lack the necessary permissions to perform the assume role action
Configuring the IAM Role Trust Policy Correctly
The trust policy of an IAM role defines which entities are allowed to assume it. When using web identity federation, this policy must explicitly trust the identity provider issuing the token. The trust policy is a JSON document that includes a principal specifying the provider and conditions to validate the token.
A correctly configured trust policy for a role assuming web identity looks like this:
“`json
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Principal”: {
“Federated”: “arn:aws:iam::123456789012:oidc-provider/oidc.example.com”
},
“Action”: “sts:AssumeRoleWithWebIdentity”,
“Condition”: {
“StringEquals”: {
“oidc.example.com:sub”: “system:serviceaccount:namespace:serviceaccountname”
}
}
}
]
}
“`
Key points to ensure:
- The `Federated` principal must exactly match the ARN of the OIDC provider configured in AWS.
- The `Action` must be `sts:AssumeRoleWithWebIdentity`.
- The `Condition` block helps restrict access to specific audience or subject values, enhancing security.
- The OIDC provider must be registered in AWS IAM beforehand.
Ensuring Proper IAM Permissions
The entity requesting to assume the role must have an IAM policy that permits `sts:AssumeRoleWithWebIdentity` on the target role. Without this permission, AWS denies the request regardless of the trust policy.
Here is an example of an IAM policy granting the necessary permission:
“`json
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: “sts:AssumeRoleWithWebIdentity”,
“Resource”: “arn:aws:iam::123456789012:role/RoleName”
}
]
}
“`
Best practices include:
- Restricting the policy scope to only the required roles.
- Avoiding wildcard (`*`) resource specifications unless absolutely necessary.
- Regularly reviewing policies for least privilege compliance.
Troubleshooting Steps to Resolve the Error
When encountering the “Not Authorized To Perform Sts Assumerolewithwebidentity” error, systematically verify the following:
- Verify OIDC Provider Registration: Ensure the identity provider is registered correctly in AWS IAM.
- Check Trust Policy: Confirm the role’s trust policy includes the correct federated principal and conditions.
- Validate IAM Permissions: Make sure the caller’s IAM policy grants `sts:AssumeRoleWithWebIdentity` for the role.
- Inspect Web Identity Token: Confirm the token is valid, unexpired, and contains the expected claims.
- Review ARN and Parameters: Verify the role ARN and other parameters used in the assume role request.
- CloudTrail Logs: Use AWS CloudTrail to analyze failed assume role attempts for additional error details.
Troubleshooting Aspect | Verification Method | Common Issues |
---|---|---|
OIDC Provider Registration | AWS Console IAM > Identity Providers | Missing or incorrect OIDC provider ARN |
Trust Policy | AWS Console IAM > Roles > Trust Relationships | Incorrect federated principal, missing sts:AssumeRoleWithWebIdentity action |
Caller Permissions | AWS Console IAM > Users/Roles > Permissions | Missing sts:AssumeRoleWithWebIdentity permission |
Web Identity Token | Decode JWT token; verify expiration and claims | Expired token, mismatched audience or subject claims |
Role ARN and Parameters | Review assume role API request parameters | Typographical errors, incorrect role ARN |
Troubleshooting the “Not Authorized To Perform Sts Assumerolewithwebidentity” Error
This error typically occurs when an AWS Identity and Access Management (IAM) entity attempts to assume a role via the Security Token Service (STS) using the `AssumeRoleWithWebIdentity` API call but lacks the necessary permissions or configuration. To resolve this issue, consider the following critical areas:
Verify IAM Role Trust Policy
The IAM role’s trust policy must explicitly allow the web identity provider (e.g., Amazon Cognito, Google, Facebook, or any OpenID Connect provider) to assume the role.
- Check the Principal: Ensure the `Principal` element includes the correct web identity provider ARN or URL.
- Action Allowed: Confirm that the trust policy allows the `sts:AssumeRoleWithWebIdentity` action.
- Condition Block: Review any conditions restricting the assumption, such as audience (`aud`) or issuer (`iss`) claims, and verify they match the token being presented.
Example trust policy snippet:
“`json
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Principal”: {
“Federated”: “arn:aws:iam::123456789012:oidc-provider/accounts.google.com”
},
“Action”: “sts:AssumeRoleWithWebIdentity”,
“Condition”: {
“StringEquals”: {
“accounts.google.com:sub”: “your-expected-subject”
}
}
}
]
}
“`
Confirm IAM Role Permissions
Even if the trust policy is correct, the IAM role must have policies attached that grant the necessary permissions for the operations that the assumed role will perform.
- Review attached IAM policies to ensure the role can perform required AWS service actions.
- Ensure no explicit deny policies are overriding permissions.
- Check for permission boundaries or service control policies (SCPs) that may restrict actions.
Validate the Web Identity Token
The token used in the `AssumeRoleWithWebIdentity` call must be valid and unexpired.
- Confirm the token was obtained from the trusted identity provider and matches the trust policy conditions.
- Verify token expiration time to avoid using stale tokens.
- Ensure the token’s claims, such as `aud` and `iss`, align with the IAM role’s trust policy.
Check AWS STS Endpoint and Region Configuration
Sometimes, the error arises due to misconfiguration in the region or endpoint the request targets.
- Ensure your SDK or CLI is configured to use the correct AWS region where the role is defined.
- Confirm the STS endpoint is accessible and not blocked by network policies.
Permissions and Trust Policy Validation Checklist
Aspect | What to Verify | Common Issues |
---|---|---|
Trust Policy Principal | Principal includes correct OIDC provider or federated identity ARN. | Using incorrect or outdated OIDC provider ARN. |
Trust Policy Action | Action allows `sts:AssumeRoleWithWebIdentity`. | Missing or incorrect action in trust policy. |
Trust Policy Conditions | Conditions match token claims (`aud`, `iss`, `sub`). | Mismatch between token claims and conditions causing denial. |
IAM Role Permissions | Role has appropriate permissions for intended AWS operations. | Insufficient permissions or explicit denies in policies. |
Token Validity | Token is unexpired and properly issued by trusted provider. | Expired or invalid tokens. |
Region and Endpoint | Correct region and STS endpoint used in API call. | Requests sent to wrong region or blocked endpoints. |
Additional Diagnostic Steps
- Enable AWS CloudTrail: Track STS `AssumeRoleWithWebIdentity` calls and identify failure reasons.
- Use AWS CLI Debugging: Run CLI commands with `–debug` to inspect request and response details.
- Check Identity Provider Configuration: Verify that the identity provider is correctly registered in IAM.
Expert Perspectives on Resolving the “Not Authorized To Perform Sts Assumerolewithwebidentity” Error
Dr. Elena Martinez (Cloud Security Architect, SecureCloud Solutions). The “Not Authorized To Perform Sts Assumerolewithwebidentity” error typically indicates a misconfiguration in IAM roles or trust policies. Ensuring that the web identity provider is correctly specified in the trust relationship and that the role has the appropriate permissions is critical. Additionally, verifying that the token from the identity provider is valid and not expired helps prevent this authorization failure.
Rajesh Kumar (Senior AWS Solutions Engineer, TechBridge Consulting). This error often arises when the IAM role’s trust policy does not explicitly allow the web identity provider to assume the role. It is essential to confirm that the “sts:AssumeRoleWithWebIdentity” action is permitted and that the audience (aud) claim in the OIDC token matches the expected value in the trust policy. Proper alignment between the identity provider, role, and token claims ensures seamless role assumption.
Linda Chen (DevOps Security Lead, CloudOps Innovations). From a DevOps perspective, encountering the “Not Authorized To Perform Sts Assumerolewithwebidentity” error often signals a gap in the integration between the application’s authentication flow and AWS IAM. It is advisable to audit both the IAM role permissions and the identity provider configuration within AWS. Implementing detailed logging and monitoring on STS calls can also expedite troubleshooting and prevent recurrence.
Frequently Asked Questions (FAQs)
What does the error “Not Authorized To Perform Sts Assumerolewithwebidentity” mean?
This error indicates that the AWS Security Token Service (STS) denied permission for the AssumeRoleWithWebIdentity API call. It typically occurs when the IAM role or identity provider does not have the necessary trust relationship or permissions configured.
What are the common causes of this authorization error?
Common causes include missing or incorrect trust policy statements for the IAM role, invalid or expired web identity tokens, or insufficient permissions assigned to the role or the identity provider.
How can I verify the trust relationship for the IAM role?
Check the role’s trust policy in the AWS IAM console or via CLI. Ensure the `Principal` element includes the correct identity provider (e.g., an OIDC provider) and that the `Action` allows `sts:AssumeRoleWithWebIdentity`.
Can incorrect token configuration lead to this error?
Yes. Using an expired, malformed, or mismatched web identity token will cause STS to deny the AssumeRoleWithWebIdentity request, resulting in this authorization error.
What steps should I take to resolve this error?
Review and update the IAM role’s trust policy to include the correct identity provider and permissions. Validate the web identity token’s validity and ensure the calling entity has permission to assume the role.
Is it necessary to configure permissions on both the IAM role and the identity provider?
Yes. The IAM role must trust the identity provider via its trust policy, and the identity provider must issue valid tokens. Both configurations must align to allow successful AssumeRoleWithWebIdentity operations.
The error “Not Authorized To Perform Sts Assumerolewithwebidentity” typically indicates a permissions issue when attempting to assume an AWS IAM role using web identity federation. This error arises when the AWS Security Token Service (STS) denies the request due to insufficient or incorrect permissions associated with the IAM role or the identity provider configuration. It is essential to verify that the IAM role’s trust policy explicitly allows the web identity provider to assume the role and that the calling entity has the necessary permissions to perform the `sts:AssumeRoleWithWebIdentity` action.
Resolving this error involves carefully reviewing the IAM role’s trust relationships, ensuring the correct audience (`aud`) claim is specified in the identity provider, and confirming that the identity token used is valid and unexpired. Additionally, the role’s permission policy must grant the required access to AWS resources once the role is assumed. Proper configuration of the identity provider, such as Amazon Cognito, Google, or any OpenID Connect (OIDC) compatible provider, is critical to successful authentication and authorization.
In summary, addressing the “Not Authorized To Perform Sts Assumerolewithwebidentity” error requires a comprehensive understanding of AWS IAM roles, trust policies, and web identity federation mechanisms
Author Profile

-
Barbara Hernandez is the brain behind A Girl Among Geeks a coding blog born from stubborn bugs, midnight learning, and a refusal to quit. With zero formal training and a browser full of error messages, she taught herself everything from loops to Linux. Her mission? Make tech less intimidating, one real answer at a time.
Barbara writes for the self-taught, the stuck, and the silently frustrated offering code clarity without the condescension. What started as her personal survival guide is now a go-to space for learners who just want to understand what the docs forgot to mention.
Latest entries
- July 5, 2025WordPressHow Can You Speed Up Your WordPress Website Using These 10 Proven Techniques?
- July 5, 2025PythonShould I Learn C++ or Python: Which Programming Language Is Right for Me?
- July 5, 2025Hardware Issues and RecommendationsIs XFX a Reliable and High-Quality GPU Brand?
- July 5, 2025Stack Overflow QueriesHow Can I Convert String to Timestamp in Spark Using a Module?