What Actually Happens During an STS AssumeRole Call
~8 min read
The concrete request/response mechanics behind temporary credential vending, and where it happens invisibly.
An AssumeRole call requires the caller to already have permission (via the target role's trust policy) to assume that specific role, and returns a temporary access key ID, secret access key, and session token, all valid only for a configured duration (a minimum of 15 minutes, up to a maximum set on the role, commonly up to 12 hours for many use cases). The permissions available with these temporary credentials are the intersection of the calling principal's own permissions (if relevant) and the target role's permission policy — practically, the assumed role's policy is what determines what the temporary credentials can actually do. Crucially, this mechanism runs invisibly behind many everyday AWS features: an EC2 instance profile, a Lambda execution role, and cross-account access via a role ARN all use AssumeRole (or equivalent STS mechanisms) under the hood, meaning most engineers use STS constantly without ever calling its API directly themselves.
💻 Code example
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/MyRole \
--role-session-name my-session \
--duration-seconds 3600
💬 Deep Dive with AI
Key points
- •AssumeRole requires the caller to have permission via the target role's trust policy
- •Returns temporary access key ID, secret key, and session token, valid only for a set duration
- •The assumed role's permission policy determines what the temporary credentials can actually do
- •EC2 instance profiles, Lambda execution roles, and cross-account access all use this mechanism invisibly