This chapter covers AWS Security Token Service (STS), a critical service for granting temporary, limited-privilege credentials to users and applications. On the CLF-C02 exam, STS falls under Domain 2: Security Compliance, Objective 2.2, which accounts for approximately 25% of the exam. Understanding STS is essential because it underpins identity federation, cross-account access, and role-based security patterns that appear frequently in exam scenarios. By the end of this chapter, you will understand how STS works, its key use cases, and how to avoid common exam traps.
Jump to a section
Imagine you run a large office building with many secure rooms. You have a security desk that issues badges. Normally, employees get a permanent badge that works for years. But sometimes, a contractor needs to access a specific server room for just one afternoon. You wouldn't give them a permanent badge—that would be a security risk. Instead, you issue a temporary VIP pass that expires at 5 PM. The contractor shows their ID (their own identity) to the security desk, and the desk issues a pass that grants access only to that room, only for today. The pass cannot be used tomorrow, and if lost, it's useless because it's tied to the contractor's face. AWS Security Token Service (STS) works exactly like this: it issues temporary, limited-privilege credentials to users or applications, reducing the risk of long-term credential exposure. The key mechanism is that STS does not create a new identity—it issues a token that represents a trusted session with specific permissions, tied to the requesting entity's existing permissions via IAM roles or federation.
What is AWS STS and What Problem Does It Solve?
AWS Security Token Service (STS) is a web service that enables you to request temporary, limited-privilege credentials for AWS Identity and Access Management (IAM) users or for users that you authenticate (federated users). The core problem STS solves is the risk associated with long-term access keys. In traditional IAM, users have access keys that do not expire unless manually rotated. If these keys are leaked, an attacker can use them indefinitely. STS issues credentials that expire after a configurable period (from 15 minutes to 36 hours, with a default of 1 hour for most API calls). These credentials consist of an access key ID, a secret access key, and a session token. The session token is a unique identifier that AWS uses to validate the temporary session. Because the credentials expire, the window of vulnerability is dramatically reduced.
How STS Works: The Mechanism
STS operates through API calls that return temporary security credentials. The most common operation is AssumeRole, which allows an IAM user or AWS service to assume a role and receive temporary credentials for that role's permissions. Here's the step-by-step mechanism:
Request: A client (IAM user, application, or federated identity) calls an STS API (e.g., AssumeRole, GetFederationToken, AssumeRoleWithWebIdentity, or AssumeRoleWithSAML). The request includes parameters like the ARN of the role to assume, a session name, and optional duration and policy restrictions.
Authentication: STS verifies the caller's identity. For AssumeRole, the caller must have IAM permissions to call sts:AssumeRole on the target role. For federated calls, the caller presents a token from an external identity provider (IdP) like Google, Facebook, or an enterprise SAML IdP.
Authorization: STS checks the trust policy of the target role to ensure the caller is allowed to assume it. The trust policy specifies which principals (users, accounts, services) can assume the role.
4. Credential Generation: If authorized, STS generates a new set of temporary security credentials. These credentials include:
- AccessKeyId: A temporary access key ID (starts with ASIA for temporary keys).
- SecretAccessKey: A temporary secret key.
- SessionToken: A token that must be included in all subsequent AWS API calls.
- Expiration: A timestamp indicating when the credentials expire.
Usage: The client uses these credentials to make AWS API calls. AWS services check the session token to validate the temporary session and enforce any session policies (like Policy parameter in AssumeRole that further restricts permissions).
Expiration: After the expiration time, the credentials become invalid. Any API call with expired credentials returns an "Access Denied" error.
Key STS API Operations
AssumeRole: The most common operation. Allows an IAM user or AWS service to assume a role in the same or different account. Returns temporary credentials for that role.
GetFederationToken: Used for custom identity federation where you manage your own identity system. Returns temporary credentials for a federated user. No role is required; you specify a policy directly.
AssumeRoleWithWebIdentity: Used for federation with web identity providers like Amazon Cognito, Google, Facebook, or any OpenID Connect (OIDC) compatible IdP. Returns temporary credentials.
AssumeRoleWithSAML: Used for federation with SAML 2.0 compatible identity providers, such as Microsoft Active Directory Federation Services (AD FS).
Temporary Credentials vs. Long-Term Credentials
| Feature | Temporary (STS) | Long-Term (IAM User) | |---------|-----------------|----------------------| | Expiration | Configurable (15 min – 36 hrs) | Never (unless rotated) | | Access Key ID prefix | ASIA | AKIA | | Session token | Required | Not used | | Use case | Roles, federation, cross-account | Direct API access, SDKs | | Risk if leaked | Limited time window | Indefinite exposure |
Service Limits and Defaults
Maximum session duration for AssumeRole: 1 hour by default, can be increased up to 12 hours (role setting).
Maximum session duration for GetFederationToken: 1 hour by default, up to 36 hours (but 1 hour is typical).
Maximum session duration for AssumeRoleWithWebIdentity and AssumeRoleWithSAML: 1 hour by default, up to 12 hours.
STS API calls are throttled: 100 requests per second per account per region (soft limit, can be increased).
You can use Policy parameter in AssumeRole to further restrict permissions for the session (session policy). This is an IAM feature that allows scoping down permissions temporarily.
Comparison to On-Premises Approaches
In on-premises environments, temporary access is often handled through service accounts with passwords that expire, or through Kerberos tickets. However, these systems lack the granularity of IAM roles and cross-account access. STS provides a cloud-native way to grant just-in-time access with audit trails via AWS CloudTrail. For example, an on-premises Active Directory might use Kerberos tickets that expire after 10 hours, but managing cross-domain trust is complex. STS with SAML federation allows seamless integration with on-premises AD while maintaining temporary credentials.
When to Use STS vs Alternatives
Use STS when: You need temporary credentials for cross-account access, federated users, or AWS services (like EC2 instances with instance profiles). Also use STS for scenarios where long-term keys are risky, such as mobile apps or web applications that need to access AWS resources.
Use IAM roles with instance profiles: For EC2 instances, you assign an IAM role to the instance, and the AWS SDK automatically uses STS to obtain temporary credentials. This is preferred over storing access keys on the instance.
Use Amazon Cognito: For user pools and identity pools, Cognito handles federation and STS token exchange automatically, simplifying mobile and web app authentication.
Avoid STS when: You need permanent credentials for a service that cannot refresh tokens (rare). Even then, consider using IAM roles with automatic rotation.
How STS Integrates with Other AWS Services
AWS CloudTrail: Records all STS API calls, including AssumeRole, for auditing. You can see who assumed which role, when, and from where.
AWS IAM: Roles and policies define who can call STS and what permissions the temporary credentials grant.
AWS Organizations: Use STS for cross-account access within an organization, often with service control policies (SCPs) that can restrict STS usage.
AWS Identity and Access Management (IAM): Temporary credentials are still governed by IAM policies; they do not bypass any permissions.
Pricing
STS itself is free of charge. You pay only for the AWS resources accessed using the temporary credentials (e.g., S3 storage, EC2 instances). There is no cost for issuing tokens, regardless of volume.
Create an IAM Role for Cross-Account Access
First, in Account A (the trusting account), create an IAM role with a trust policy that allows Account B (the trusted account) to assume it. For example, the trust policy might specify `"Principal": { "AWS": "arn:aws:iam::ACCOUNT-B-ID:root" }`. The role also has a permissions policy that defines what actions the temporary credentials can perform, such as reading from an S3 bucket. This is the foundation: without a properly configured trust policy, STS will reject the request.
Call AssumeRole API from Account B
An IAM user or service in Account B calls the `AssumeRole` STS API with the ARN of the role created in Account A. The request must include a session name (e.g., `"cross-account-session"`) and optionally a duration (default 1 hour). The IAM user in Account B must have permissions to call `sts:AssumeRole` on that specific role ARN. If the user lacks this permission, the call fails with an access denied error. This step ensures that only authorized entities can request temporary credentials.
Receive Temporary Credentials
STS returns a JSON object containing `AccessKeyId`, `SecretAccessKey`, `SessionToken`, and `Expiration`. The `AccessKeyId` starts with `ASIA` to indicate temporary credentials. The `SessionToken` is a long string that must be included in all subsequent AWS API calls. The credentials are typically valid for 1 hour by default, but can be set from 15 minutes up to 12 hours depending on the role's maximum session duration setting. The calling application must store these credentials securely and plan to refresh them before expiration.
Use Temporary Credentials to Access Resources
The application uses the temporary credentials to make AWS API calls. For example, to list objects in an S3 bucket in Account A, the application sets the `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_SESSION_TOKEN` environment variables, or uses the AWS SDK with a credentials object that includes the session token. AWS services check the session token and validate that the session is still active and within its expiration time. The permissions are exactly those defined in the role's policy, possibly further restricted by any session policy passed in the `AssumeRole` call.
Monitor and Audit with CloudTrail
Every STS API call is logged in AWS CloudTrail. You can view who assumed the role, the source IP address, the session name, and the duration. This is crucial for compliance and security investigations. For example, if you see an `AssumeRole` call from an unexpected account, you can investigate. CloudTrail also logs the temporary credentials usage, but note that the credentials themselves are not logged—only the `AssumeRole` event. This step is often tested on the exam: STS calls are always recorded in CloudTrail, providing an audit trail.
Business Scenario 1: Cross-Account Access for DevOps Teams
A company has multiple AWS accounts: a production account and a development account. The DevOps team needs to occasionally access the production account to deploy updates, but they should not have permanent access. The company creates an IAM role in the production account with a trust policy that allows the development account to assume it. The role has a permissions policy that grants only the necessary actions (e.g., ec2:StartInstances, ec2:StopInstances). The DevOps team uses AssumeRole from their development account to get temporary credentials. This reduces the risk of permanent credentials being leaked. If misconfigured—for example, if the trust policy allows any user from the development account to assume the role—an attacker who compromises a developer's account could access production. The solution is to restrict the trust policy to specific IAM users or roles.
Business Scenario 2: Federation with Corporate Active Directory
A large enterprise uses Microsoft Active Directory for employee identities. They want employees to access AWS resources using their corporate credentials. They set up SAML federation: the corporate IdP (e.g., AD FS) authenticates the user, then calls AssumeRoleWithSAML to exchange a SAML assertion for temporary AWS credentials. The user never receives long-term AWS keys. This centralizes identity management and allows the company to enforce multi-factor authentication (MFA) on the corporate side. Cost is minimal: STS is free, and the IdP may have licensing costs. A common misconfiguration is not properly mapping SAML attributes to IAM role session tags, leading to incorrect permissions. Also, if the SAML assertion expires (typically 1 hour), the user cannot access AWS until they re-authenticate.
Business Scenario 3: Mobile App Access to AWS Resources
A startup builds a mobile app that lets users upload photos to an S3 bucket. Using Amazon Cognito Identity Pools, the app authenticates users via Facebook or Google, then exchanges the social token for temporary AWS credentials via AssumeRoleWithWebIdentity. The credentials have limited permissions—only s3:PutObject to a specific folder. This avoids storing AWS keys in the mobile app, which would be insecure. A common mistake is granting too broad permissions (e.g., s3:*), allowing a malicious user to delete all objects. The correct approach is to use IAM policy variables (like ${cognito-identity.amazonaws.com:sub}) to restrict access to the user's own folder. Also, if the web identity token is not validated properly, an attacker could forge tokens. AWS handles validation when using Amazon Cognito.
What CLF-C02 Tests on STS
The CLF-C02 exam includes questions about STS under Domain 2: Security Compliance. You need to know:
The purpose of STS: issue temporary credentials.
The difference between temporary and long-term credentials.
Common STS API operations: AssumeRole, GetFederationToken, AssumeRoleWithWebIdentity, AssumeRoleWithSAML.
Use cases: cross-account access, identity federation, EC2 instance profiles.
That STS is free to use.
That temporary credentials expire and must be refreshed.
That AssumeRole requires both the caller's IAM permissions and the role's trust policy.
Common Wrong Answers and Why Candidates Choose Them
"STS can be used to create permanent IAM users." – Wrong because STS only issues temporary credentials. Candidates confuse STS with IAM, which creates permanent users. The exam tests this distinction: STS does not create or manage IAM users.
"STS credentials are valid indefinitely." – Wrong because temporary credentials have an expiration. Candidates assume that since IAM keys are permanent, STS keys are too. The exam tests the expiration aspect.
"STS is used to encrypt data at rest." – Wrong because STS is about access control, not encryption. Candidates might confuse STS with KMS or CloudHSM. The exam tests that STS is for authentication/authorization, not encryption.
"You need to pay per STS request." – Wrong because STS is free. Candidates might think all AWS services have costs. The exam tests that STS has no additional charge.
Specific Terms and Values That Appear on the Exam
ASIA: Prefix for temporary access key IDs.
AKIA: Prefix for permanent access key IDs.
Session token: Required for temporary credentials.
AssumeRole: The most commonly tested API.
Trust policy: The policy on the role that defines who can assume it.
Duration: Default 1 hour, max 12 hours for roles.
Cross-account access: A key use case.
Tricky Distinctions
STS vs. IAM Roles: IAM roles are the container for permissions; STS is the service that issues credentials for the role. They work together. The exam might ask: "Which service provides temporary credentials?" Answer: STS.
STS vs. Amazon Cognito: Cognito handles user authentication and federation; it uses STS behind the scenes to issue credentials. The exam might ask: "Which service can exchange a Facebook token for AWS credentials?" Answer: Cognito Identity Pools (which uses STS).
STS vs. AWS IAM Identity Center: Identity Center provides a central place to manage user access across multiple accounts; it also uses STS for temporary credentials. But Identity Center is a separate service with its own portal.
Decision Rule for Multi-Choice Questions
If the question asks about granting temporary access to AWS resources, the answer likely involves STS. If the question mentions "federation" or "cross-account," think STS. If the question asks about permanent keys, think IAM. Eliminate any answer that suggests STS creates permanent credentials, requires payment, or is used for encryption.
AWS STS issues temporary, limited-privilege credentials for IAM users or federated users.
Temporary credentials consist of an access key ID (starts with ASIA), a secret access key, and a session token.
The default session duration is 1 hour, configurable from 15 minutes up to 12 hours (for AssumeRole) or 36 hours (for GetFederationToken).
STS is free; you only pay for the resources accessed using the temporary credentials.
Common STS API operations: AssumeRole, GetFederationToken, AssumeRoleWithWebIdentity, AssumeRoleWithSAML.
Cross-account access requires a role with a trust policy that allows the external account to assume it.
All STS API calls are logged in AWS CloudTrail for auditing.
IAM roles for EC2 instances use STS to automatically obtain temporary credentials via instance profiles.
STS does not create or manage IAM users; it only issues credentials.
To use temporary credentials, include the session token in every AWS API request.
These come up on the exam all the time. Here's how to tell them apart.
AWS STS
Issues temporary credentials with expiration
Access key ID starts with ASIA
Requires session token in API calls
Used for roles, federation, cross-account access
Free to use
AWS IAM Users & Long-Term Keys
Issues permanent credentials that do not expire
Access key ID starts with AKIA
No session token required
Used for direct API access by users or applications
No additional cost, but keys are a security risk if leaked
Mistake
STS can create permanent IAM users.
Correct
STS only issues temporary credentials that expire. IAM is used to create permanent users and access keys.
Mistake
STS credentials do not require a session token.
Correct
All temporary credentials from STS include a session token that must be included in every AWS API request. Without the session token, the request fails.
Mistake
STS is a paid service.
Correct
STS is free to use. You only pay for the AWS resources accessed with the temporary credentials.
Mistake
AssumeRole can be called by anyone without permissions.
Correct
The caller must have IAM permissions to call sts:AssumeRole on the target role, and the role's trust policy must allow the caller. Both conditions must be met.
Mistake
Temporary credentials from STS are valid for up to 36 hours by default.
Correct
The default session duration is 1 hour. It can be set up to 12 hours for AssumeRole (role setting) or up to 36 hours for GetFederationToken.
AssumeRole is used when an IAM user or AWS service wants to assume a specific IAM role, either in the same or a different account. It returns temporary credentials for that role. GetFederationToken is used for custom identity federation where you manage your own identity system; it does not require a role—you pass a policy directly. GetFederationToken is typically used when you have your own authentication system and want to issue temporary credentials without creating an IAM role. On the exam, remember that AssumeRole is the most common and is used for cross-account access.
Yes. This is called cross-account access. You create an IAM role in Account A with a trust policy that allows Account B to assume it. An IAM user in Account B calls AssumeRole, receives temporary credentials, and uses them to access resources in Account A. This is a key use case tested on the CLF-C02 exam.
You can call the same STS API again (e.g., AssumeRole) before the current credentials expire. The new credentials will have a new expiration time. For long-running applications, it's common to refresh credentials every 30-60 minutes. AWS SDKs can handle this automatically if you configure a credentials provider that refreshes tokens.
STS is a global service with a single global endpoint (sts.amazonaws.com) and also regional endpoints. By default, STS calls go to the global endpoint. However, you can use regional endpoints for lower latency or to meet data residency requirements. The exam may ask about regional endpoints, but the global endpoint is most common.
You cannot make API calls without the session token. The temporary credentials are invalid without it. You must call STS again to get new credentials. This is why it's important to store the entire credential set securely.
Yes. You can require MFA in the role's trust policy or pass an MFA token in the AssumeRole call. For example, you can use `aws:MultiFactorAuthPresent` condition key in the trust policy to require MFA. This adds an extra layer of security.
Yes. AWS SDKs have built-in support for STS. For example, you can use the `STSClient` in the AWS SDK for Java or `boto3.client('sts')` in Python. SDKs can also automatically refresh credentials if you use a role provider like `AssumeRoleCredentialProvider`.
You've just covered AWS Security Token Service (STS) — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?