If you’ve ever wondered why you would need AWS STS (Security Token Service), imagine this:

You’re managing access for a growing team working across multiple AWS accounts, each with varying levels of data sensitivity and specific permissions. You need a solution that provides quick, secure access without exposing long-term credentials. STS allows you to issue temporary, limited-privilege credentials that make accessing AWS resources both efficient and secure.

In this article, we’ll explore everything you need to know about AWS STS: how it works, its key features, and best practices. 

What is AWS STS?

AWS Security Token Service (STS) is a service that issues short-term, limited-privilege credentials to AWS Identity and Access Management (IAM) users or federated users requiring temporary access to AWS resources. These temporary credentials are a better alternative to long-term access keys, which could pose security risks. AWS STS is often used for federated access, cross-account access, or by applications that need to assume IAM roles. So, you can ensure that STS credentials expire after a specific time, reducing the likelihood of misuse.

Let’s say you’ve just launched a new service on AWS—perhaps a custom API or an application running in an EC2 instance—that your external partners need to access securely. These partners use their own systems outside of AWS, and you want to ensure they only access specific resources without the risk of long-term credentials. In this case, you’d have them authenticate, and then configure their application to assume an IAM role you’ve created. This role, managed through AWS STS, will grant them the minimal permissions needed to interact with the service temporarily, providing both security and flexibility.

Key Features of AWS STS

Temporary Security Credentials

A standout feature of AWS Security Token Service (AWS STS) is its ability to issue temporary security credentials for trusted users. Unlike traditional, long-term access keys, temporary credentials offer short-term, secure access to AWS resources, tailored to each user’s needs and usage duration.

Here’s how they work: temporary credentials are created dynamically upon request and are valid for a specific time frame, from a few minutes up to several hours. Once this time expires, AWS automatically revokes access, and any subsequent API calls using these credentials are denied. Users can, however, request new temporary credentials as needed, provided they still have the required permissions.

This feature is particularly advantageous for a few reasons:

• Enhanced Security: Temporary credentials remove the need for long-term keys, reducing security risks in applications.
• No Dedicated Identity Needed: Users can access AWS resources without individual IAM accounts, ideal for roles and federated access.
• Automatic Expiration: Credentials expire on their own, simplifying management and reducing the risk of outdated credentials.

Moreover, temporary credentials can be generated through AWS STS’s global endpoint or from specific AWS regional endpoints, which reduces latency for users accessing resources in different geographic locations.

Cross-Account Access

AWS Security Token Service (STS) makes it easy to access resources securely across different AWS accounts by using temporary credentials instead of long-term ones. Here’s how it works:

1. Imagine you have two AWS accounts—Account A and Account B. Account A needs to allow users or applications from Account B to access its resources. To do this, Account A creates an IAM role with specific permissions and sets it up to trust users from Account B.
2. When a user or application in Account B needs to access resources in Account A, they send a request to assume the IAM role in Account A. This request is made through the AWS STS AssumeRole API.
3. If everything checks out (such as permissions and trust settings), AWS STS issues temporary security credentials—a set of keys that are only valid for a limited time. These temporary keys allow the user or application to perform the actions allowed by the IAM role in Account A.
4. The user or application in Account B can now use these credentials to access resources in Account A, like reading an S3 bucket or accessing a Lambda function. The permissions are strictly limited to what’s defined in the IAM role.
5. Once the temporary credentials expire, access is automatically revoked. If the user or application needs access again, they’ll have to request new temporary credentials.

Here’s an example of a cross-account access:

Image source: Amazon’s blog about AWS services

Using temporary credentials through AWS STS, you get a secure way to share resources between AWS accounts without the risks of long-term keys. It’s flexible, secure, and only allows access when needed.

Federated Access

Let’s say you have contractors or partners who need secure access to specific AWS resources, but you don’t want to set up permanent IAM accounts for each user. This is where federated access in AWS STS shines. Federated access lets users from outside AWS access resources without individual AWS accounts by establishing a system of trust called identity federation.

Here’s how it works: users authenticate through an Identity Provider (IdP), like Okta or Microsoft Active Directory, where they log in and verify their identity. Once authenticated, the IdP sends AWS a secure message, known as an assertion, with information about the user. AWS STS then uses this assertion to issue temporary credentials based on a specific IAM role, granting the user access to only the resources they need and only for a limited time.

AWS provides two main options for managing federated access:

• AWS IAM Identity Center

Ideal if you want a centralized system for managing access across multiple AWS accounts. With Identity Center, users log in once and have single sign-on (SSO) access to all assigned resources and applications.

• AWS Identity and Access Management (IAM)

Useful for setting up more customized access, where permissions are based on attributes like job role or department through attribute-based access control (ABAC).

So, AWS STS easily integrates with common identity providers, supporting open standards like SAML 2.0 and OpenID Connect (OIDC). And Federated access simplifies identity management and grants the exact access needed, when it’s needed, and nothing more.

Regional Availability

AWS STS supports regional availability, allowing you to choose between a global endpoint or specific regional endpoints for temporary credential requests. While the global endpoint (https://sts.amazonaws.com) is hosted in the US East (N. Virginia) and is highly available, it doesn’t offer automatic failover across other AWS regions. For most use cases, AWS recommends using regional endpoints over the global endpoint due to these advantages:

1. Reduced Latency: When you make AWS STS calls to an endpoint in a region geographically closer to your services and applications, you can lower latency and improve response times, as requests are processed locally rather than routed to a centralized endpoint.
2. Built-In Redundancy: Regional endpoints offer fault isolation. When you align STS calls to specific regions, you can contain potential failures within that region, minimizing the impact on other components and improving the reliability of your setup. This fault isolation aligns with AWS’s Well-Architected Framework, ensuring a more resilient architecture.
3. Increased Session Token Validity: Tokens generated from regional STS endpoints are valid across all AWS regions, which makes them compatible with any region you enable in the future. In contrast, tokens from the global endpoint are valid only in regions enabled by default, limiting flexibility if you expand to new regions.

You can access a list of AWS STS Regions and their endpoints here AWS STS Regions and endpoints.

How AWS STS Works

How to request temporary security credentials

1. Request – A user or application sends a request to AWS STS for temporary credentials.
2. Authenticate – The request includes details about the IAM role to be assumed and the permissions needed.
3. Receive Credentials – AWS STS verifies the request. If everything checks out, it returns a temporary access key, secret access key, and session token.
4. Access AWS Resources – The temporary credentials allow the user or application to access AWS resources based on the permissions granted in the assumed role.

Key API Operations in AWS STS

1. AssumeRole grants temporary access to users or applications in one AWS account to assume a role in another account. It’s commonly used for cross-account access.
2. GetSessionToken provides temporary credentials for users who have AWS credentials but want short-term access to resources. It’s often used when additional security factors are required.
3. AssumeRoleWithSAML is used for federated access when users authenticate through Security Assertion Markup Language (SAML). This operation enables SSO for applications using external identity providers.
4. AssumeRoleWithWebIdentity is designed for applications that authenticate users through web identity providers (like Google, Facebook, or Amazon Cognito) to access AWS resources.

Workflow Example: Assuming a Role Using AWS STS

Let’s have a look at an example workflow for a user assuming a role in another AWS account:

1. Initiate Request – The user or application in Account A calls the AssumeRole API to access resources in Account B.
2. Include Role Details – The request includes the Role ARN (Amazon Resource Name) of the role in Account B and the session duration.
3. AWS STS Verification – AWS STS verifies the request and checks if the user in Account A is allowed to assume the role in Account B.
4. Issue Temporary Credentials – If the verification is successful, AWS STS returns temporary credentials (an access key, secret key, and session token).
5. Access Resources – Using the temporary credentials, the user can now perform actions in Account B as specified by the role’s permissions.
6. Expiration – When the session ends, the temporary credentials automatically expire, and access is revoked.

Use Cases and Best Practices of AWS STS

Make the most of Amazon Web Services Security Tokens Service in these steps:

Security Considerations

When configuring AWS STS and IAM, taking steps to further enhance security is essential to protecting AWS environments. Here are key considerations to keep in mind:

Access Key Management
Regularly review and update long-term access keys, using IAM Access Analyzer to identify and remove unused or outdated keys. Whenever possible, rely on temporary credentials, which expire automatically, reducing security risks.

Permissions Boundaries and Service Control Policies (SCPs)
In multi-account setups, use permissions boundaries and SCPs within AWS Organizations to set access limits. Permissions boundaries control delegated permissions, while SCPs create consistent permissions across accounts, helping maintain a secure structure.

Regular Review of Unused Access
Periodically review and remove unused IAM users, roles, and permissions to keep only necessary access active. Last-accessed data helps identify inactive credentials, supporting least-privilege principles.

Policy Validation with IAM Access Analyzer
Before deploying IAM policies, validate them with IAM Access Analyzer to ensure secure syntax and identify any risks. This tool can also generate policies based on actual access patterns, making it easy to follow best practices.

Protect Root User Credentials
Limit the use of root credentials, enable MFA for added security, and use IAM roles or federated access wherever possible to avoid logging in with root access. This keeps high-level permissions limited to essential tasks only.

Limitations of AWS STS

Duration Limitations on Temporary Credentials

Temporary credentials from AWS STS only last for a limited time – up to 12 hours in most cases (sometimes 36 hours with certain IAM policies). While this time limit improves security, it may not work well for applications or workflows that need continuous access. For long-running tasks, using long-term credentials or another AWS identity service might be a better choice.

Performance with High-Frequency Requests

AWS STS isn’t built for handling a high volume of requests in rapid succession. Frequent requests can lead to slower response times, especially if you’re using the global STS endpoint instead of regional ones. For applications that need quick, repeated access, using regional endpoints can help improve performance, though frequent reauthentication can still create some delay.

AWS STS vs Amazon Cognito (Alternative)