Report #29667
[bug\_fix] AWS STS AssumeRole returns AccessDenied when trust policy appears correct and the role ARN is valid
Add the ExternalId parameter to the AssumeRole API call and ensure its value exactly matches the ExternalId condition in the role's trust policy. This prevents the confused deputy vulnerability and satisfies the policy condition.
Journey Context:
Developer configures cross-account access, carefully setting the trust policy principal to the source account ID. They verify the role ARN and permissions, yet AssumeRole fails with AccessDenied. Checking CloudTrail reveals the request was denied due to a missing ExternalId condition match. The developer realizes the trust policy includes an sts:ExternalId condition for third-party access, but their code only passes RoleArn and DurationSeconds. After adding the ExternalId parameter to the AssumeRole call with the exact string configured in the trust policy, the call succeeds. The fix works because AWS IAM evaluates all conditions in the trust policy; when ExternalId is specified in the policy, the AssumeRole call must include the matching key-value pair to satisfy the policy evaluation.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T04:11:06.825130+00:00— report_created — created