AWS Security Token Service (STS): What It Is and When to Use It

Definition

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). It is a fundamental security service that solves the problem of using long-term access keys, instead promoting the best practice of using short-lived credentials to access AWS resources.

How It Works

STS acts as a trusted third party to "vend" temporary credentials. An authenticated principal (an IAM user, an application running on an AWS service, or a federated user) makes a call to an STS API endpoint. STS validates the request and, if successful, returns a set of temporary credentials. These credentials consist of three parts: an Access Key ID, a Secret Access Key, and a Session Token. Any subsequent API calls to AWS services must use all three of these components to be authenticated and authorized.

The core of STS revolves around IAM Roles. An IAM Role is an identity with permission policies that determine what the identity can and cannot do in AWS. A role is intended to be assumable by anyone who needs it. It has a Trust Policy that specifies which principals are allowed to assume the role, and a Permissions Policy that defines the access rights granted with the role's temporary credentials.

A typical AssumeRole flow is as follows:

An IAM User or application in Account A wants to access a resource (e.g., an Amazon S3 bucket) in Account B.
The administrator of Account B creates an IAM Role. The role's Trust Policy explicitly allows the IAM User (or its parent account) from Account A to assume it.
The IAM User in Account A makes an sts:AssumeRole API call, specifying the Amazon Resource Name (ARN) of the role in Account B.
STS verifies that the Trust Policy of the role in Account B allows the call from the user in Account A.
If verified, STS returns temporary credentials (Access Key, Secret Key, Session Token) to the user in Account A.
The user in Account A can now use these temporary credentials to make API calls to access the S3 bucket in Account B, subject to the permissions defined in the role's Permissions Policy.

Key API Operations

AssumeRole: The most common operation, used for cross-account access and for AWS services to act on your behalf.
AssumeRoleWithSAML: Used for identity federation with enterprise identity systems that support SAML 2.0, like Active Directory Federation Services (ADFS).
AssumeRoleWithWebIdentity: Used for identity federation with public identity providers (IdPs) that are OpenID Connect (OIDC) compliant, such as Google, Facebook, or Amazon Cognito.
GetSessionToken: Used by an existing IAM user or AWS account root user to obtain temporary credentials. This is often used to provide temporary access for processes or to validate a user's identity with Multi-Factor Authentication (MFA).
GetFederationToken: A legacy operation for delegating permissions, typically used by a custom identity broker. It creates a temporary "federated user" session.

Key Features and Limits

Temporary Credentials: The core feature is the generation of short-lived credentials, which enhances security by reducing the risk associated with compromised long-term keys.
Session Duration: The duration of temporary credentials is configurable. For AssumeRole, the session can last from 15 minutes (900 seconds) to a maximum of 12 hours (43,200 seconds). For GetSessionToken, the duration can be up to 36 hours for IAM users.
Role Chaining Limit: When you use one assumed role's credentials to assume a second role (a practice known as role chaining), the session duration for any chained role is limited to a maximum of one hour.
Global and Regional Endpoints: STS is a global service by default (sts.amazonaws.com), but AWS recommends using regional STS endpoints (e.g., sts.us-east-1.amazonaws.com) to reduce latency and improve application availability.
Session Policies: When assuming a role, you can pass an inline or managed IAM policy. The resulting session's permissions are the intersection of the role's identity-based policy and the session policies, allowing for further restriction of privileges.
Session Tags: You can pass key-value pair tags during an AssumeRole call. These tags can be used in IAM policies for Attribute-Based Access Control (ABAC) to create fine-grained permissions.
Service Quotas: STS API calls are subject to throttling. While these limits are high and suitable for most workloads, high-traffic applications should implement retry logic with exponential backoff. You can view current quotas in the AWS documentation.

Common Use Cases

Cross-Account Access: The primary use case is to allow users or services in one AWS account to securely access resources in another account without creating duplicate IAM users. This is foundational for multi-account strategies, such as separating development, testing, and production environments.
Identity Federation: STS is the engine for federating external identities into AWS.
- SAML 2.0 Federation: Allows enterprise users to sign into the AWS Management Console or get programmatic access using their corporate credentials from an identity provider like Okta or Azure AD.
- Web Identity (OIDC) Federation: Enables mobile and web applications to grant users secure access to AWS resources after they have authenticated with a public provider like Google, Facebook, or Amazon Cognito.
IAM Roles for AWS Services: Services like Amazon EC2, AWS Lambda, and Amazon ECS use STS to assume an IAM role on your behalf. This allows the service to obtain temporary credentials to interact with other AWS services (e.g., an EC2 instance writing logs to Amazon CloudWatch or reading an object from Amazon S3).
Privileged Access Management (PAM): Instead of granting developers standing high-privilege access, they can be given standard user permissions and required to assume a specific, highly-audited role for a short duration to perform administrative tasks.

Pricing Model

AWS Security Token Service (STS) is offered at no additional charge. You only pay for the other AWS services that are accessed using the temporary security credentials vended by STS. For more details on the pricing of other services, refer to the AWS Pricing Calculator.

Pros and Cons

Pros:

Enhanced Security: Follows the principle of least privilege by providing temporary, auto-expiring credentials, which significantly reduces the attack surface compared to static, long-lived keys.
Centralized Access Management: Enables federation from external identity providers, allowing organizations to use their existing identity systems as the source of truth.
Granular Permissions: Session policies and session tags allow for dynamic, fine-grained control over permissions for a specific session.
Improved Auditability: All STS actions, such as AssumeRole, are logged in AWS CloudTrail, providing a clear audit trail of who accessed what and when.

Cons:

Increased Complexity: Managing trust policies, role permissions, and federation configurations can be more complex than managing simple IAM users, especially at scale.
Credential Management in Applications: Applications must be coded to handle temporary credentials, which includes refreshing the credentials before they expire.
Role Chaining Limitations: The one-hour session limit for chained roles can be a constraint for long-running automated jobs or complex cross-account workflows.
Revocation Complexity: You cannot explicitly revoke a single set of active temporary credentials. The primary method to invalidate sessions is to attach a deny policy to the parent role or user, which affects all sessions issued before a certain time.

Comparison with Alternatives

STS (IAM Roles) vs. IAM Users: An IAM User represents a person or application with permanent, long-lived credentials. An IAM Role, accessed via STS, does not have its own credentials and is meant to be assumed temporarily by trusted principals. Best Practice: Use IAM Roles and STS for nearly all access patterns, including for applications and human users. Reserve IAM users for specific administrative accounts or for principals that need to initiate the first AssumeRole call.
STS vs. AWS IAM Identity Center (formerly AWS SSO): IAM Identity Center is a higher-level service built on top of IAM and STS. It simplifies the management of single sign-on (SSO) and multi-account access for human users. For managing workforce access across an AWS Organization, IAM Identity Center is the recommended approach as it automates the creation of roles and the configuration of federation, abstracting away the manual STS setup. STS remains the underlying engine and is used directly for application-level cross-account access or more customized federation scenarios.

Exam Relevance

AWS STS is a critical topic on several AWS certification exams, particularly those focused on security, architecture, and development.

AWS Certified Security - Specialty (SCS-C03): Expect in-depth questions on designing authentication and authorization mechanisms, including when and how to use STS for federation and cross-account access.
AWS Certified Solutions Architect - Associate (SAA-C03) & Professional (SAP-C02): Understanding STS and IAM Roles is fundamental for designing secure and scalable multi-account architectures.
AWS Certified Developer - Associate (DVA-C02): Candidates need to know how to use STS programmatically within applications to securely access AWS services using temporary credentials.

Key topics to know include the AssumeRole process, the difference between SAML and Web Identity Federation, the components of temporary credentials (including the session token), and the purpose of a role's trust policy.

Frequently Asked Questions

Q: What is the difference between an IAM role and an IAM user?

A: An IAM user is an identity with permanent, long-term credentials (a password or access keys) that represents a specific person or application. An IAM role is an identity with specific permissions that can be assumed by trusted entities (like IAM users, applications, or AWS services); it does not have its own long-term credentials and instead provides temporary credentials via STS.

Q: How do I revoke active STS temporary credentials?

A: You cannot directly revoke a specific set of temporary credentials before they expire. The recommended method to invalidate active sessions for a role is to go to the IAM console, select the role, and choose "Revoke sessions." This attaches an inline policy to the role that denies all actions for sessions issued before the current time, effectively invalidating them.

Q: What is role chaining and what are its limits?

A: Role chaining is the process of using temporary credentials from one role to assume a second role. This is common in hub-and-spoke account models. The primary limitation is that any session created through chaining has a maximum duration of one hour, regardless of the maximum session duration configured on the target role.

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS documentation before making production decisions.