AWS STS: A Complete Guide to AWS Security Token Service

Introduction

Managing secure access in AWS environments often involves balancing convenience and security. AWS Security Token Service (AWS STS) plays a pivotal role in this balance by allowing users to generate temporary security credentials. As an integral component of AWS Identity and Access Management (IAM), AWS STS helps you implement robust, fine-grained access control while minimizing security risks.

In this comprehensive guide, we’ll dive deep into AWS STS, covering what it is, how it functions behind the scenes, its key features, and practical ways to leverage it through various real-world use cases.

What is AWS STS?

AWS Security Token Service (AWS STS) is an Amazon Web Services feature designed to generate temporary, limited-privilege security credentials that allow users and applications secure access to AWS resources. Unlike long-term credentials, these short-lived tokens significantly minimize security risks and simplify secure cross-account or federated access.

AWS STS provides temporary security credentials composed of three critical components:

1. Access Key ID

The Access Key ID acts as a unique public identifier, similar to a username, allowing AWS to recognize who is making the request. It’s paired with the Secret Access Key to authenticate your programmatic calls to AWS services.

2. Secret Access Key

The Secret Access Key serves as a confidential credential, comparable to a password. It’s used in conjunction with the Access Key ID to digitally sign requests, ensuring authenticity and security. To maintain the integrity of your AWS environment, the Secret Access Key must remain private and protected.

3. Session Token

The Session Token is an additional layer of security provided with temporary credentials. It’s mandatory for authenticating programmatic requests made using temporary credentials, particularly when Multi-Factor Authentication (MFA) is enabled. This ensures heightened security, reducing the risk if credentials are compromised.

AWS STS-generated credentials typically last from as short as 15 minutes up to a maximum duration of 12 hours. Once expired, these credentials are invalidated automatically by AWS and cannot be reused. If continued access is required beyond expiration, a new set of credentials must be requested.

By using AWS STS, organizations benefit from enhanced security, streamlined access management, and minimized risk associated with credential exposure or misuse.

How AWS STS Works

When requesting temporary credentials through AWS STS, the service follows a structured process to ensure security and proper access control:

1. Request Submission

An IAM user, role, federated user, or AWS service initiates a request to AWS STS for temporary security credentials. Typically, this request is made using an API call, AWS SDK, CLI command, or AWS Management Console.

2. Authentication and Authorization

Upon receiving the request, AWS STS authenticates the identity of the requester. It then evaluates the IAM policies and permissions associated with the user or assumed role to ensure the requester is authorized for the requested actions.

3. Credential Issuance

If authentication and authorization checks pass successfully, AWS STS generates a set of temporary security credentials, which includes an Access Key ID, a Secret Access Key, and a Session Token. These credentials inherit permissions defined by the user’s policies or the IAM role assumed.

4. Resource Access Using Temporary Credentials

The requester can now use the temporary credentials to access AWS resources. All subsequent API calls made using these temporary credentials are evaluated based on the permissions inherited during issuance, ensuring access remains tightly controlled and secure.

5. Credential Expiration

Each set of AWS STS credentials has a limited lifespan, typically ranging from 15 minutes to 12 hours. Once this duration expires, AWS automatically invalidates the credentials. To maintain continued access, a new set of credentials must be requested. This limited validity period greatly reduces the security risks associated with compromised credentials.

Through this structured workflow, AWS STS provides robust security, enabling secure temporary access to AWS resources and significantly reducing the potential impact of credential misuse or leakage.

The Process of Assuming Roles

To assume an IAM role using AWS STS, a Trust Relationship policy is essential. This policy explicitly defines which entities—such as users, IAM roles, AWS services, or even external identities—are allowed to assume the role, providing an added layer of security.

Here’s the complete workflow for setting up and assuming IAM roles via AWS STS:

1. Create an IAM Role

Start by creating an IAM role that specifies the exact permissions granted once assumed. This defines the scope and limitations of access.

2. Define the Trust Relationship

Specify the entities permitted to assume the role by creating or editing the role’s Trust Policy. This explicitly lists allowed entities, enhancing security through controlled access.

3. Entity Requests Credentials

When a permitted entity needs temporary access, it sends an aws sts assume-role request to AWS STS, typically via CLI, SDK, or API.

4. AWS STS Validates the Trust Relationship

AWS STS evaluates the trust policy to verify that the requesting entity is explicitly permitted to assume the role. If the entity is not listed or authorized, the request is denied.

5. Issue Temporary Credentials

Once AWS STS successfully validates the requesting entity against the trust policy, it generates and returns temporary security credentials (Access Key ID, Secret Access Key, and Session Token).

Example Trust Relationship Policy

Here’s an illustrative trust policy allowing a specific IAM user from another AWS account to assume the role:

In this example:

• Only the IAM user ExampleUser from AWS account 111122223333 can assume the specified role.
• Any request from other entities will automatically be denied, ensuring strict security.

Key AWS STS API Actions and Their Use Cases

Let’s dive deeper into some essential AWS STS API actions and explore practical real-world scenarios where you would leverage them:

1. aws sts assume-role

The assume-role API call allows IAM users, applications, or AWS services to temporarily assume an IAM role, gaining the permissions associated with it.

Common Use Cases:

• Cross-Account Access: Safely granting users from one AWS account temporary access to resources in another without exposing permanent credentials.
• Federated Authentication: Allowing external identity providers or federation services to manage access permissions securely.
• Delegating Access: Providing temporary permissions to applications or services, avoiding the risk of sharing long-term credentials.

Example AWS CLI command:

aws sts assume-role \\
--role-arn arn:aws:iam::123456789012:role/demo \\
--role-session-name MySession


2. aws sts get-session-token

The get-session-token API generates temporary credentials for IAM users or AWS account root users, typically when additional security via Multi-Factor Authentication (MFA) is required.

Common Use Cases:

• Enhanced Security with MFA: Securing access to sensitive AWS actions and resources by requiring temporary, MFA-authenticated credentials.
• Short-term Elevated Access: Providing brief access periods with controlled permissions and MFA enforcement, significantly reducing the risk of credential misuse.

Example AWS CLI command:

aws sts get-session-token \\
--duration-seconds 3600 \\
--serial-number arn:aws:iam::123456789012:mfa/user \\
--token-code 123456


3. aws sts get-caller-identity

The get-caller-identity API returns information about the IAM identity currently associated with the provided credentials, including the AWS account ID, ARN, and user or role ID.

Common Use Cases:

• Identity Validation and Troubleshooting: Quickly verifying the identity associated with credentials during troubleshooting or debugging.
• Security Auditing: Confirming the correct permissions and roles assigned to identities for compliance and audit purposes.

Example AWS CLI command:

aws sts get-caller-identity


4. aws sts assume-role-with-saml

The assume-role-with-saml API call allows users to assume an IAM role after being authenticated via a Security Assertion Markup Language (SAML) authentication response. This is particularly useful for integrating AWS with corporate identity providers that support SAML.

Common Use Cases:

•Enterprise Single Sign-On (SSO): Enabling federated users from a SAML-compliant identity provider to access AWS resources without the need for separate AWS credentials.

Example AWS CLI command:

aws sts assume-role-with-saml \\
 --role-arn arn:aws:iam::123456789012:role/demo \\
 --principal-arn arn:aws:iam::123456789012:saml-provider/ExampleSAMLProvider \\
 --saml-assertion file://saml-response.xml


5. aws sts assume-role-with-web-identity

The assume-role-with-web-identity API call allows users who have been authenticated in a mobile or web application with a web identity provider (such as Amazon, Facebook, or Google) to assume an IAM role. This facilitates granting temporary AWS access to users already authenticated by these external providers.

Common Use Cases:

• Mobile and Web Application Access: Granting temporary AWS credentials to users authenticated through external identity providers, enabling them to access AWS resources without managing separate AWS credentials.

Example AWS CLI command:

aws sts assume-role-with-web-identity \\
 --role-arn arn:aws:iam::123456789012:role/demo \\
 --role-session-name MySession \\
 --web-identity-token file://web-identity-token.jwt \\
 --provider-id www.amazon.com


6. aws sts get-federation-token

The get-federation-token API call provides temporary security credentials to federated users. This is particularly useful for integrating AWS with external identity systems, allowing users authenticated elsewhere to access AWS resources temporarily.

Common Use Cases:

• Temporary Access for Federated Users: Providing external users with temporary AWS credentials, enabling them to access AWS resources without creating individual IAM users.

Example AWS CLI command:

aws sts get-federation-token \\
 --name ExampleName \\
 --policy '{"Version": "2012-10-17", "Statement": [{"Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::example_bucket"}]}' \\
 --duration-seconds 3600


7. aws sts decode-authorization-message

The decode-authorization-message API call decodes additional information about the authorization status of a request from an encoded message returned in response to an AWS request. This is useful for understanding the details of authorization failures.

Common Use Cases:

• Debugging Authorization Failures: Decoding error messages to gain insights into why a request was denied, aiding in troubleshooting and policy corrections.

Example AWS CLI command:

aws sts decode-authorization-message \\
 --encoded-message AQoDYXdzE...H


Best Practices When Using AWS STS

When implementing AWS Security Token Service (STS), adopting the following best practices ensures enhanced security and minimizes potential risks:

1. Implement Short-Lived Tokens

Always configure temporary security credentials to have the shortest duration necessary for the specific task. Short-lived credentials reduce exposure time, minimizing the potential damage if credentials are compromised.

2. Utilize MFA for Privileged Actions

For sensitive operations or highly privileged access, integrate AWS STS credentials with Multi-Factor Authentication (MFA). Requiring MFA adds an essential layer of security, ensuring that only authorized users can perform critical actions.

3. Regularly Audit Trust Policies

Periodically review and audit IAM role trust policies. Ensure that only necessary users or services have permission to assume roles, reducing the risk of unintended or unauthorized access.

4. Leverage IAM Roles Instead of IAM Users for Applications

When granting AWS resource access to applications, use IAM roles instead of IAM user credentials. Roles provide temporary, automatically rotated credentials, significantly reducing security risks associated with static credentials.

5. Principle of Least Privilege

Grant roles and temporary credentials the minimal set of permissions required for their intended tasks. Limiting permissions helps prevent accidental or malicious misuse of credentials.

6. Monitor and Log Credential Usage

Enable AWS CloudTrail to continuously log all AWS STS API calls. Monitoring credential usage provides insights into access patterns, aids troubleshooting, and supports security auditing efforts.

Following these best practices strengthens your overall security posture when leveraging AWS STS, protecting your environment from unauthorized access and credential misuse.

Recent Changes to AWS STS

AWS recently introduced significant updates regarding the AWS Security Token Service (STS) endpoints. The primary change involves shifting from using the global STS endpoint to utilizing specific regional endpoints. This update aims to enhance security, reduce latency, and improve overall service reliability.

AWS strongly recommends migrating to regional endpoints, as this approach ensures compliance with regional data governance standards, enhances fault tolerance, and optimizes performance by reducing response times.

Adopting this updated guidance helps maintain best practices in security and delivers an improved experience when using AWS STS.

Conclusion

AWS Security Token Service (STS) is a powerful feature within AWS IAM, enabling secure and flexible management of temporary credentials. By leveraging AWS STS, you significantly reduce security risks associated with static credentials and simplify complex access scenarios, such as cross-account access and federated authentication.

Adopting best practices—like short-lived tokens, MFA enforcement for sensitive actions, regular auditing, and adherence to the principle of least privilege—further enhances your organization’s security posture. Additionally, transitioning to AWS STS regional endpoints aligns your setup with AWS’s latest recommendations, improving compliance, performance, and reliability.

Overall, integrating AWS STS into your AWS environment helps build a robust and secure foundation, allowing your organization to confidently manage access control and identity management challenges in the cloud.

Optimize Your AWS Environment with Cloudchipr

While AWS STS enhances your security by simplifying identity management and access control, optimizing your overall cloud expenses is another essential aspect of running a robust cloud infrastructure—especially when managing resources across multi-cloud environments.

Cloudchipr easily integrates with your AWS workflow, enabling you to manage cloud costs efficiently without sacrificing performance or security. Our platform simplifies multi-cloud cost optimization across AWS, Azure, and GCP, helping you control spending and streamline operations.

Key Features of Cloudchipr

‍Automated Resource Management:‍

Identify and eliminate idle or underutilized resources with intuitive, no-code automation workflows. This helps reduce wasteful spending while maintaining a secure, efficient cloud environment.

Rightsizing Recommendations:

Get data-driven suggestions on optimal instance sizes, storage configurations, and compute resources. Achieve the performance you need without overspending, ensuring a robust foundation for your security measures.

Commitments Tracking:

Monitor your Reserved Instances and Savings Plans to maximize their utilization. With clear visibility into your commitments, you can optimize costs while supporting your security investments.

Live Usage & Management:

Track real-time resource consumption and performance metrics across AWS, Azure, and GCP. Quickly identify inefficiencies and make proactive adjustments, complementing your AWS GuardDuty insights for a holistic view of your cloud operations.

Try Cloudchipr Risk-Free

Discover the benefits of integrated multi-cloud management and proactive cost optimization firsthand. Sign up today for your 14-day free trial—no obligations, no hidden fees.