External ID and the Confused Deputy

When you let a third party assume a role in your account, a security risk called the confused deputy problem can arise. The external ID is the simple but vital control that prevents it. This pattern appears on the exam whenever a SaaS vendor needs access to your AWS account.

A confused deputy is a trusted entity (the deputy) that is tricked into using its authority on behalf of an attacker. In AWS, a third-party service has permission to assume roles in many customer accounts; an attacker could trick it into assuming your role if nothing ties the request to the legitimate customer relationship.

Imagine a monitoring SaaS that assumes a role in each customer account. The SaaS uses one AWS identity for everyone. If an attacker who is also a customer guesses your role ARN, they might persuade the SaaS to assume your role, since the SaaS is the trusted principal. Account ID alone is not enough to stop this.

The external ID is a unique, secret value the vendor assigns to your relationship. You put it in your role's trust policy as a condition, and the vendor must supply the exact same value when calling AssumeRole. Because the attacker does not know your external ID, they cannot trick the vendor into assuming your role.

This trust policy requires the matching external ID. AssumeRole succeeds only when the vendor passes the identical value, defeating the confused-deputy attack.

Crucially, the vendor generates and controls the external ID, not the customer. This prevents customers from colluding to reuse the same value. AWS guidance is explicit: as a third party, you must assign each customer a unique external ID and require it on every assumption.

The external ID is not meant to be a secret like a password; it can appear in setup instructions. Its security value comes from being unique per customer and controlled by the vendor, so an attacker cannot make the deputy use the wrong customer's value. Treat it as an anti-impersonation token, not a credential.

The external ID controls who can assume, but you still scope what the role can do with tight permission policies. Even a correctly authorized vendor should receive only the minimum permissions needed. Combine external ID, a specific principal, and least-privilege permissions for safe third-party access.

The confused-deputy pattern also applies to AWS services acting on your behalf. Service-to-service trust often uses condition keys like aws:SourceArn and aws:SourceAccount in resource policies to ensure the calling service is acting for your resource, the same defensive idea in a different wrapper.

Whenever a question describes a third-party or SaaS assuming a role across accounts, the secure answer almost always involves an external ID in the trust policy. If the scenario is service-to-service, look for aws:SourceArn/aws:SourceAccount conditions instead. Recognizing the cue points you straight to the right control.

The confused deputy problem lets an attacker trick a trusted third party into misusing its access. The external ID, unique per customer and controlled by the vendor, prevents it by requiring a matching value on AssumeRole. For AWS services, use aws:SourceArn and aws:SourceAccount. Always pair these with least-privilege permissions.

Test the confused-deputy concept.

The confused deputy problem arises when a trusted third party is tricked into misusing its cross-account access. The external ID, unique per customer and controlled by the vendor, prevents it via a trust-policy condition on sts:ExternalId. For AWS service-to-service trust, use aws:SourceArn and aws:SourceAccount, always with least privilege.