This chapter covers AWS Security Token Service (STS), a core service for granting temporary, limited-privilege credentials to users or applications. You will learn the three main STS operations: AssumeRole, GetSessionToken, and AssumeRoleWithWebIdentity. For the SAA-C03 exam, STS appears in approximately 10-15% of questions, often integrated with IAM roles, identity federation, and cross-account access. Mastering STS is essential for designing secure, scalable architectures.
Jump to a section
Imagine a hotel with a master key system. The hotel manager (AWS root user) holds a master key that can open every room and storage closet. Instead of handing out copies of the master key to every employee (which is risky), the manager uses a key card encoding machine (AWS STS). A housekeeper needs to enter room 304 for cleaning. The manager inserts the master key into the machine, selects 'room 304, valid for 1 hour', and the machine produces a temporary key card (temporary credentials) that only opens room 304. The housekeeper uses this card, and after 1 hour, the card's magnetic stripe demagnetizes automatically (expiration). The housekeeper cannot access room 305 or the storage closet. Similarly, for a guest who booked through a third-party website (web identity), the front desk uses a code from the third party (identity token) to issue a temporary key card that only works for their specific room and check-out date. The master key is never exposed, and each temporary card has minimal permissions and a short lifespan.
What is AWS STS and Why It Exists
AWS Security Token Service (STS) is a web service that enables you to request temporary, limited-privilege credentials for IAM users or federated users. These credentials consist of an Access Key ID, Secret Access Key, and a Security Token. Temporary credentials are valid for a configurable duration, from 15 minutes to 36 hours, depending on the API call. The primary purpose of STS is to reduce the risk of long-term credential exposure. Instead of embedding permanent IAM user keys in applications or distributing them to users, you issue temporary credentials that expire automatically. This is critical for cross-account access, role delegation, and identity federation.
How STS Works Internally
When you call an STS API (e.g., AssumeRole), the service performs the following steps: 1. Authentication: The caller must provide valid AWS credentials that have permission to call the STS API. For AssumeRole, the caller needs sts:AssumeRole permission on the target role. 2. Authorization: AWS evaluates the IAM policy of the caller and the trust policy of the target role. The trust policy specifies which principals (accounts, users, or services) are allowed to assume the role. 3. Credential Generation: STS generates a new set of temporary credentials. The Access Key ID starts with 'ASIA' (for temporary credentials). The Secret Access Key is a cryptographically random string. The Security Token is a base-64 encoded opaque string that must be included in all subsequent requests. 4. Session Policy: Optionally, you can pass a session policy that further restricts the role's permissions for that specific session. The effective permissions are the intersection of the role's permissions and the session policy. 5. Expiration: The credentials have a lifetime specified in the request (default varies by API). After expiration, the credentials become invalid and any API calls using them receive an 'ExpiredToken' error.
Key STS API Operations
#### AssumeRole - Purpose: To obtain temporary credentials for a specific IAM role. Used for cross-account access or role delegation within the same account. - Parameters:
RoleArn: The ARN of the role to assume.
RoleSessionName: An identifier for the session, used in CloudTrail logs.
Policy (optional): A session policy to restrict permissions.
DurationSeconds: Session duration (900 to 43200 seconds, i.e., 15 minutes to 12 hours; for roles with a maximum session duration set in the role, the max is 36 hours).
Example CLI command:
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/MyRole --role-session-name MySessionResponse: Includes Credentials (AccessKeyId, SecretAccessKey, SessionToken, Expiration), AssumedRoleUser (Arn, AssumedRoleId), and PackedPolicySize.
#### GetSessionToken - Purpose: To obtain temporary credentials for an IAM user, typically for MFA-enabled sessions or to extend the user's credential lifetime. Does not require a role. - Parameters:
DurationSeconds: 900 to 129600 seconds (15 minutes to 36 hours). Default is 1 hour.
SerialNumber (optional): The ARN of the MFA device.
TokenCode (optional): The time-based one-time password (TOTP) from the MFA device.
Use case: An IAM user wants to perform sensitive operations and is required to use MFA. The user calls GetSessionToken with MFA parameters, and the resulting temporary credentials have the same permissions as the user, but the session is MFA-authenticated.
Example CLI:
aws sts get-session-token --serial-number arn:aws:iam::123456789012:mfa/MyUser --token-code 123456#### AssumeRoleWithWebIdentity - Purpose: To obtain temporary credentials for users authenticated by a web identity provider (e.g., Google, Facebook, Amazon Cognito). This is used for mobile or web applications that need AWS access. - Parameters:
RoleArn: The ARN of the role to assume.
RoleSessionName: Session name.
WebIdentityToken: The token from the identity provider (e.g., Google ID token, Facebook access token).
ProviderId (optional): For providers like Google or Facebook, you may need to specify the provider's ID.
DurationSeconds: 900 to 43200 seconds (15 minutes to 12 hours). Default is 1 hour.
Important: The role's trust policy must trust the web identity provider. The token must be valid and from a trusted issuer.
Example CLI:
aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789012:role/MyWebRole --role-session-name WebSession --web-identity-token eyJhbGci...Default Values, Timers, and Limits
Default session duration:
AssumeRole: 1 hour (if not specified, but the role's maximum session duration is used; if not set, default is 1 hour).
GetSessionToken: 1 hour.
AssumeRoleWithWebIdentity: 1 hour.
Maximum session duration:
AssumeRole: 12 hours (or up to 36 hours if the role's maximum session duration is set to that value).
GetSessionToken: 36 hours.
AssumeRoleWithWebIdentity: 12 hours.
Minimum session duration: 15 minutes for all APIs.
Credential size: The maximum size of the credentials (including session policy) is 1024 bytes. If you exceed this, STS returns a 'PackedPolicyTooLarge' error.
Rate limits: By default, you can make up to 100 STS API calls per second per account. For AssumeRole, you can have up to 1000 concurrent sessions per role (though this is a soft limit).
Interaction with IAM Policies
Trust Policy: A policy attached to the role that specifies who can assume the role. For cross-account access, the trust policy includes the AWS account ID of the trusted account. For web identity, it includes the provider's ARN.
Permissions Policy: The policy attached to the role that defines what the assumed session can do.
Session Policy: An optional policy passed during AssumeRole that further restricts the role's permissions. The effective permissions are the intersection of the role's permissions and the session policy (i.e., the most restrictive).
Condition Keys: You can use condition keys like aws:SourceIp, aws:MultiFactorAuthPresent, and aws:RequestedRegion in the trust policy to enforce additional constraints.
Verification Commands
To verify temporary credentials, you can use the AWS CLI with the --profile option or set environment variables:
aws sts get-caller-identity --profile MyTemporaryProfileOr via environment variables:
export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
aws sts get-caller-identityIf the credentials are valid, you'll see the ARN of the assumed role or user. If expired, you'll get an 'ExpiredToken' error.
How STS Interacts with Other Services
IAM Roles for EC2: EC2 instances can use an instance profile with a role. The instance automatically calls STS AssumeRole to get temporary credentials for the role. The credentials are rotated automatically before expiration.
AWS Lambda: Lambda functions can be assigned an execution role. Lambda uses STS internally to obtain credentials for the function.
Amazon Cognito: Cognito Identity Pools use STS to issue temporary credentials for authenticated users. Cognito handles the AssumeRoleWithWebIdentity call on behalf of the user.
CloudTrail: All STS API calls are logged in CloudTrail, including the assumed role ARN and session name.
Security Best Practices
Always use temporary credentials instead of long-term access keys.
Set the shortest practical session duration.
Use session policies to scope down permissions for each session.
Require MFA for sensitive operations using GetSessionToken.
Monitor STS usage with CloudTrail and set up alerts for unusual patterns.
For cross-account roles, use external IDs to prevent the confused deputy problem.
Initiate AssumeRole API Call
A user or service (the caller) makes an AssumeRole API call to STS. The caller must have valid AWS credentials (e.g., an IAM user's access key) and must be authorized by the role's trust policy. The call includes the RoleArn, a RoleSessionName, and optionally a session policy and duration. The caller's identity is authenticated by AWS Signature V4. The request is sent to the STS endpoint (e.g., sts.amazonaws.com).
STS Authenticates and Authorizes
STS verifies the caller's credentials and checks that the caller has the sts:AssumeRole permission on the target role. It then evaluates the role's trust policy to see if the caller is allowed to assume the role. The trust policy may include conditions such as MFA requirements, source IP, or time of day. If the caller passes these checks, STS proceeds to generate temporary credentials.
Generate Temporary Credentials
STS generates a new set of temporary credentials: an AccessKeyId (starting with ASIA), a SecretAccessKey, a SessionToken, and an Expiration timestamp. The credentials are cryptographically tied to the role and the session. The session policy (if provided) is combined with the role's permissions policy to determine the effective permissions. The credentials are valid for the requested duration (default 1 hour, max 12-36 hours).
Return Credentials to Caller
STS returns the temporary credentials to the caller in the API response. The response also includes the AssumedRoleUser ARN (e.g., arn:aws:sts::123456789012:assumed-role/MyRole/MySession) and an AssumedRoleId. The caller can then use these credentials to make AWS API calls. The caller must include the SessionToken in all subsequent requests.
Use Credentials for AWS API Calls
The caller uses the temporary credentials to make AWS API calls. The credentials are passed via the Authorization header (using AWS Signature V4) or via environment variables. AWS services verify the credentials by checking the AccessKeyId and SessionToken with STS. If the credentials are expired, the service returns an 'ExpiredToken' error. If the credentials are valid but lack permissions, an 'AccessDenied' error is returned.
Enterprise Scenario 1: Cross-Account Access for Centralized Logging
A large enterprise has multiple AWS accounts (dev, prod, security). The security team wants to collect CloudTrail logs from all accounts into a central S3 bucket in the security account. The security account creates an IAM role (LogCollectorRole) with permissions to write to the S3 bucket. Each other account creates a role that trusts the security account's role and has a policy allowing sts:AssumeRole. The security team uses a script that assumes the LogCollectorRole in each target account using AssumeRole, obtains temporary credentials, and then uses those credentials to copy logs. This avoids storing long-term keys in the script. Common misconfiguration: forgetting to update the trust policy when adding new accounts, causing AssumeRole to fail with 'AccessDenied'. Also, session duration must be long enough to complete the log transfer; if logs take longer than 1 hour, the script must refresh the credentials.
Enterprise Scenario 2: Mobile App with Web Identity Federation
A company builds a mobile app that allows users to upload photos to S3. Users authenticate via Facebook or Google. The app uses Amazon Cognito Identity Pools, which internally calls AssumeRoleWithWebIdentity. When a user logs in, the app receives an identity token from the provider. The app sends this token to Cognito, which validates it and then calls STS AssumeRoleWithWebIdentity to get temporary credentials for a role that has permissions to write to a user-specific S3 prefix. The credentials are cached on the device and refreshed automatically. A common issue: if the identity provider token expires before the STS credentials, the user may need to re-authenticate. The solution is to configure the session duration to be shorter than the token lifetime. Also, if the role's trust policy is not correctly configured to trust the provider, STS returns 'AccessDenied'.
Enterprise Scenario 3: MFA-Protected Administrative Access
An organization requires all IAM users to use MFA before performing sensitive operations like deleting S3 buckets or modifying IAM policies. Users first call GetSessionToken with their MFA device to get temporary credentials that have the MFA context. These credentials are then used for the sensitive API calls. The IAM policy for the sensitive action includes a condition aws:MultiFactorAuthPresent set to true. If a user attempts the action without MFA, the call fails. A common mistake: users forget to call GetSessionToken first and try to use their long-term credentials, which lack the MFA context. The solution is to enforce MFA via IAM policies and educate users to use GetSessionToken. Also, the session duration for GetSessionToken should be set to a reasonable value (e.g., 1 hour) to avoid forcing MFA re-entry too frequently.
SAA-C03 Exam Focus on STS
The SAA-C03 exam tests STS primarily in the context of Secure Architectures (Domain 1) and Design for High Availability (Domain 2). Specific objectives include: - 1.1: Design secure access to AWS resources (STS, IAM roles, cross-account access). - 1.2: Design secure application tiers (web identity federation). - 2.1: Design scalable and elastic architectures (temporary credentials for auto-scaling instances).
Common Wrong Answers and Why Candidates Choose Them
Using GetSessionToken for cross-account access: Candidates often assume that GetSessionToken can be used to access another account. Wrong. GetSessionToken only works for the same IAM user in the same account. For cross-account, you must use AssumeRole.
Assuming that temporary credentials are permanent: Some think that temporary credentials can be renewed indefinitely without re-authentication. In reality, they have a fixed lifetime and must be refreshed by calling STS again.
Confusing AssumeRole with GetFederationToken: GetFederationToken is a different STS API for custom identity brokers, not covered in SAA-C03. The exam focuses on AssumeRole, GetSessionToken, and AssumeRoleWithWebIdentity.
Thinking that web identity tokens can be used directly: Candidates may think that a Facebook token can be used directly to access AWS. Actually, you must call AssumeRoleWithWebIdentity (or use Cognito) to exchange the token for AWS credentials.
Specific Numbers and Terms That Appear on the Exam
Default session duration: 1 hour for AssumeRole and GetSessionToken.
Maximum session duration: 12 hours for AssumeRole (36 hours if role allows).
Minimum session duration: 15 minutes.
Credential prefix: AccessKeyId starts with 'ASIA'.
'PackedPolicyTooLarge' error: when session policy exceeds 1024 bytes.
'ExpiredToken' error: when using expired credentials.
Condition key aws:MultiFactorAuthPresent for MFA.
Role trust policy vs permissions policy.
Edge Cases and Exceptions
If a role's maximum session duration is set to 36 hours, but the caller requests 12 hours, the session lasts 12 hours. If the caller requests 48 hours, the request fails.
When using session policies, the effective permissions are the intersection of the role's policy and the session policy. If the session policy grants permissions not in the role's policy, those are ignored.
For AssumeRoleWithWebIdentity, the trust policy must trust the web identity provider (e.g., accounts.google.com). If the provider is not trusted, the call fails.
STS endpoints are regional. You can specify a regional endpoint (e.g., sts.us-east-1.amazonaws.com) to reduce latency, but the credentials work globally.
How to Eliminate Wrong Answers
If a question mentions cross-account access, eliminate any answer that uses GetSessionToken or IAM user keys.
If a question involves mobile app users authenticating via Google, look for AssumeRoleWithWebIdentity or Cognito.
If a question requires MFA, the correct answer will involve GetSessionToken with MFA parameters or a condition key.
If a question asks about extending credential lifetime, remember that you cannot extend temporary credentials; you must call STS again before expiration.
STS temporary credentials consist of AccessKeyId (starts with ASIA), SecretAccessKey, and SessionToken.
AssumeRole is the primary API for cross-account access; requires a role with a trust policy.
GetSessionToken is used for MFA-enabled sessions; does not change the user's permissions.
AssumeRoleWithWebIdentity is used for federated users from web identity providers like Google or Facebook.
Default session duration is 1 hour for all STS APIs; minimum is 15 minutes.
Session policies are optional and further restrict permissions (intersection, not union).
Temporary credentials expire and cannot be renewed; you must call STS again to get new credentials.
STS API calls are logged in CloudTrail for auditing.
These come up on the exam all the time. Here's how to tell them apart.
AssumeRole
Used for cross-account access or role delegation.
Requires a role ARN and trust policy.
Credentials are tied to the assumed role, not the original user.
Session duration: 15 minutes to 12 hours (up to 36 hours if role allows).
Returns AssumedRoleUser ARN.
GetSessionToken
Used for MFA-protected sessions or extending user credentials.
Does not require a role; uses the caller's IAM user.
Credentials have the same permissions as the original IAM user.
Session duration: 15 minutes to 36 hours.
Returns the original user's ARN.
Mistake
GetSessionToken can be used to access resources in another AWS account.
Correct
GetSessionToken returns credentials for the same IAM user in the same account. For cross-account access, you must use AssumeRole with a role in the target account.
Mistake
Temporary credentials from STS never expire.
Correct
All STS credentials have a configurable expiration time (15 minutes to 36 hours). After expiration, they become invalid and cannot be used.
Mistake
AssumeRoleWithWebIdentity can be used without a role trust policy.
Correct
The role's trust policy must explicitly trust the web identity provider (e.g., 'accounts.google.com'). Without this, the call fails with AccessDenied.
Mistake
You can use a web identity token (e.g., Facebook access token) directly to call AWS APIs.
Correct
AWS does not accept third-party tokens directly. You must call AssumeRoleWithWebIdentity to exchange the token for temporary AWS credentials.
Mistake
Session policies can grant permissions beyond the role's existing permissions.
Correct
Session policies only restrict permissions; they cannot grant additional permissions. The effective permissions are the intersection of the role's policy and the session policy.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
AssumeRole is used to obtain temporary credentials for a specific IAM role, typically for cross-account access or to delegate permissions. The resulting credentials are tied to the role, not the original user. GetSessionToken is used to obtain temporary credentials for the same IAM user, often to enforce MFA or to extend the credential lifetime. GetSessionToken does not change the user's permissions; it just provides a temporary credential set with the same permissions.
The duration is configurable. For AssumeRole, the minimum is 15 minutes, maximum is 12 hours (or up to 36 hours if the role's maximum session duration is set higher). For GetSessionToken, the minimum is 15 minutes, maximum is 36 hours. For AssumeRoleWithWebIdentity, the minimum is 15 minutes, maximum is 12 hours. The default is 1 hour for all APIs.
Yes, by using AssumeRole. You create a role in the target account with a trust policy that allows the source account's IAM users or roles to assume it. Then, you call AssumeRole with the role's ARN to get temporary credentials that can access resources in the target account.
A session policy is an optional IAM policy that you pass when calling AssumeRole. It further restricts the permissions of the temporary credentials. The effective permissions are the intersection of the role's permissions policy and the session policy. This means the session policy can only limit, not expand, the role's permissions.
Yes. Although temporary credentials are less risky than long-term keys because they expire, they should still be protected. Avoid hardcoding them in applications. Use environment variables, AWS Secrets Manager, or IAM roles for EC2/Lambda to manage them securely. If compromised, they are only valid for a limited time.
AWS returns an 'ExpiredToken' error. The API call fails. To avoid this, you must refresh the credentials before they expire by calling STS again. For automated systems, implement credential rotation logic.
Yes. For IAM users, you can call GetSessionToken with an MFA device ARN and TOTP code to get temporary credentials that have the MFA context. Then, you can use IAM policies with the condition key 'aws:MultiFactorAuthPresent' to require MFA for certain actions.
You've just covered STS: AssumeRole, GetSessionToken, and Web Identity — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?