8.3 AWS Security Token Service (STS) & Temporary Credential Workflows

8.3 AWS Security Token Service (STS) & Temporary Credential Workflows

Long-term static security credentials—such as IAM user access keys and secret keys—represent one of the most severe attack vectors in cloud security. If hardcoded into application source code, committed to public repositories, or leaked via compromised developer workstations, static credentials give adversaries persistent, unmonitored access to AWS environments. The AWS Security Token Service (STS) eliminates this vulnerability by providing a globally distributed, cryptographically robust web service that vends temporary, short-lived security credentials.

A rigorous understanding of STS API operations, temporary credential anatomy, session policies, session duration boundaries, role chaining limitations, and S3 presigned URL mechanics is essential for passing the AWS Certified Security – Specialty exam.

---

AWS STS Architecture & Temporary Credential Anatomy

AWS STS enables trusted entities (IAM users, federated identities, AWS services, and external workloads) to request ephemeral credentials on demand. Unlike static IAM credentials, temporary credentials are not stored in the IAM database and do not require manual rotation.

Anatomy of Temporary Credentials

Whenever STS successfully processes an authentication request, it returns a response payload containing four critical elements:

1. AccessKeyId: A unique string identifying the temporary credential. Crucial Exam Indicator: Temporary access key IDs always begin with the prefix ASIA (e.g., ASIAQWERTYUIOP123456), whereas long-term IAM user access keys begin with the prefix AKIA (e.g., AKIAIOSFODNN7EXAMPLE).
2. SecretAccessKey: The cryptographic secret used to calculate HMAC signatures for AWS Signature Version 4 (SigV4) requests.
3. SessionToken: An encrypted, variable-length token string containing internal cryptographic session metadata, expiration time, and security constraints. When making API calls with temporary credentials, the SessionToken must be passed in the X-Amz-Security-Token HTTP header or query string.
4. Expiration: An ISO 8601 UTC timestamp indicating the exact date and time when the credentials become invalid. Once this timestamp passes, any AWS API call made with these credentials fails immediately with an ExpiredTokenException.

---

Comprehensive Comparative Analysis of STS API Operations

AWS STS provides five core API operations. Each operation serves a distinct architectural use case and enforces specific constraints:

Loading diagram...

Key Differences Between Operations for the Exam

• Credentials to Call: AssumeRole and GetSessionToken require valid AWS credentials to call. In contrast, AssumeRoleWithWebIdentity and AssumeRoleWithSAML do not require prior AWS credentials; the caller presents an external cryptographic token (OIDC JWT or SAML assertion) directly to STS.
• GetSessionToken vs. AssumeRole: GetSessionToken does not assume a role. It returns temporary credentials for the existing IAM user who called it. Crucially, GetSessionToken does not support session policies. To scope down permissions dynamically, you must use AssumeRole or GetFederationToken.

---

Session Policies: Mathematical Intersection & Runtime Scoping

When assuming a role via AssumeRole, AssumeRoleWithWebIdentity, or AssumeRoleWithSAML, the caller can optionally pass an inline or managed Session Policy as a parameter in the API call.

Mathematical Intersection Logic

A session policy is an advanced authorization tool used to scope down permissions dynamically at runtime. The fundamental rule of session policies is mathematical intersection:

Effective Permissions = [Role Identity-Based Policies]  INTERSECT  [Session Policy]

Loading diagram...

Practical Security Rules for Session Policies

1. Permissions Can Only Be Restricted, Never Expanded: If an IAM role has AdministratorAccess and the caller passes a session policy allowing only s3:GetObject on my-bucket, the resulting session can only execute s3:GetObject on my-bucket. Conversely, if the role allows only s3:GetObject and the caller passes a session policy allowing s3:* and ec2:*, the effective permission remains strictly s3:GetObject. A session policy can never grant permissions that the underlying role does not already possess.
2. Explicit Deny Precedence: If either the role policy OR the session policy contains an explicit Deny, the request is denied unconditionally.
3. Use Case: Multi-tenant SaaS applications where a single shared worker role assumes itself or a downstream role, passing a dynamic session policy that restricts access strictly to the tenant's specific S3 prefix or DynamoDB partition key.

---

Role Session Duration & The Role Chaining Boundary

Session Duration Configuration

When an IAM role is created, its default maximum session duration is 1 hour. An administrator can modify this setting on the role up to 12 hours using the MaxSessionDuration attribute.

• When a caller invokes AssumeRole, they specify the DurationSeconds parameter.
• The requested DurationSeconds must be between 900 seconds (15 minutes) and the role's configured MaxSessionDuration.
• If a caller requests a DurationSeconds greater than the role's MaxSessionDuration, the call fails with a ValidationError.

The 1-Hour Role Chaining Limitation

Role Chaining occurs when an assumed role session uses its temporary credentials to assume another IAM role (e.g., Role A assumes Role B, or Role A -> Role B -> Role C):

Loading diagram...

CRITICAL EXAM TRAP: In role chaining, the maximum session duration for any chained role session is strictly capped at 1 hour (3,600 seconds), regardless of the MaxSessionDuration setting configured on the target role! Even if Role B has its MaxSessionDuration set to 12 hours, when Role A assumes Role B, any request for a session duration longer than 3,600 seconds will fail, and the session will expire after at most 1 hour. This AWS security design limits the blast radius of chained credential compromises.

---

Amazon S3 Presigned URLs & Temporary Credential Delegation

An Amazon S3 Presigned URL grants temporary read or write access to an S3 object to anyone who possesses the URL, using the cryptographic permissions of the identity that generated it. Presigned URLs are widely used in secure architectures to allow users or external systems to upload or download files directly from S3 without proxying data through application servers.

Presigned URL Expiration Rules: Static vs. Temporary Credentials

The maximum validity period of an S3 presigned URL depends strictly on the type of credentials used to generate it:

Exam Scenario: An application assumes a role with the default 1-hour session and generates an S3 presigned download URL with an expiration of 24 hours (86400 seconds). The client tries to download the file 3 hours later and receives HTTP 403 with an expired-token error. Why? The role session that signed the URL expired after 1 hour. A presigned URL signed with temporary credentials cannot outlive those credentials. For long-lived links, sign with an IAM user's access key (up to 7 days) or use a different distribution method such as CloudFront signed URLs.

---

Regional STS Endpoints vs. The Global STS Endpoint

Older AWS SDKs and CLI configurations (setting legacy) send STS requests to the global STS endpoint (sts.amazonaws.com). Historically that endpoint was served only from us-east-1 (N. Virginia). Since 2025, AWS serves global-endpoint requests in the caller's own Region when the workload runs in a Region that is enabled by default and uses Amazon-provided DNS. Requests from opt-in Regions, or through custom DNS that doesn't resolve to the local Region, are still served by us-east-1. Current SDK major versions default to regional.

The Security and Resilience Risk of the Global Endpoint

1. Cross-Region Latency: An application running in ap-southeast-1 (Singapore) sending every AssumeRole call to us-east-1 incurs significant network latency.
2. Blast Radius and Single Point of Failure: Workloads whose global-endpoint requests are still served by us-east-1 (opt-in Regions, custom DNS, or on-premises callers) lose credential vending if us-east-1 is impaired.
3. Data Sovereignty / Compliance: Certain regulatory frameworks mandate that security credentials and API calls must never leave a specific geographic boundary (e.g., the European Union).

Activating Regional STS Endpoints

AWS provides Regional STS endpoints (e.g., sts.eu-west-1.amazonaws.com, sts.ap-northeast-1.amazonaws.com):

• Session Token Validity: Session tokens from Regional endpoints are valid in all AWS Regions. Tokens from the global endpoint are valid only in Regions enabled by default unless you change the global endpoint token version to v2 in IAM account settings.
• Configuration: Applications should set the environment variable AWS_STS_REGIONAL_ENDPOINTS=regional or configure the AWS SDK client to use the regional endpoint.
• Fault Isolation: If us-east-1 experiences an outage, workloads using Regional STS endpoints in other Regions continue obtaining temporary credentials. Make sure each Regional endpoint is active in IAM account settings (Regions enabled by default have it active).

---

Specialty Exam Pitfalls & Architectural Traps

1. Role Chaining Beyond 1 Hour: Questions describing cross-account deployment pipelines where an orchestration role assumes an intermediate role, which then assumes an environment admin role, frequently test session duration. Remember: the chained session cannot exceed 1 hour.
2. Session Policies Cannot Escalate Privileges: If a question suggests using a session policy to grant an assumed role additional permissions that the role itself does not possess, that option is false. Session policies only filter/intersect.
3. STS GetSessionToken Does Not Support Session Policies: Attempting to pass a session policy to GetSessionToken causes an API validation exception. Use AssumeRole or GetFederationToken when session policy restriction is needed.
4. Revoking Active STS Sessions: Once an STS temporary credential is vended, it cannot be directly deleted or revoked via a simple API call. To immediately invalidate an active temporary credential session, an administrator must attach an inline policy to the role containing a condition that denies access based on the aws:TokenIssueTime condition key (e.g., denying all actions where aws:TokenIssueTime is earlier than the revocation timestamp).