AWS Security Token Service (STS)

AWS Security Token Service (STS) provides temporary security credentials to enable short-term access to AWS resources. STS is critical in cross-account access, federated authentication, service-to-service communication, and session-based access control, eliminating the need for long-term credentials.

Scenario 1: Cross-Account Access Using AssumeRole

Use Case: An IAM user or AWS service in Account A needs to access resources in Account B.

How STS is Involved

1. The IAM user or service in Account A requests temporary credentials by calling sts:AssumeRole for a role in Account B.

2. STS validates the trust policy on the target IAM role and issues temporary credentials.

3. The IAM user or service uses these credentials to access AWS resources in Account B.

4. Once the temporary credentials expire, the user must assume the role again.

---

Scenario 2: AWS Identity Center (SSO) User Accessing an AWS Account

Use Case: A user logs into AWS via AWS Identity Center (SSO) and is granted temporary credentials to access an AWS account.

How STS is Involved

1. The user authenticates via AWS Identity Center, which may be backed by an external Identity Provider (IdP) such as Okta, Active Directory, or Google.

2. Based on configured permission sets, Identity Center determines which IAM roles the user can assume.

3. AWS Identity Center automatically calls STS to assume the role and retrieve temporary credentials.

4. The user gains access to AWS resources using the credentials issued by STS.

5. Once the credentials expire, the user must log in again via Identity Center.

---

Scenario 3: Federated Access with an External Identity Provider (IdP)

Use Case: A user authenticates via an external Identity Provider (IdP) (e.g., Okta, Azure AD, Google) and receives temporary AWS credentials.

How STS is Involved

1. The user logs into the external IdP, which authenticates their identity.

2. The IdP generates a SAML assertion or OIDC token that the user presents to AWS.

3. The user calls STS AssumeRoleWithSAML (for SAML-based IdPs) or STS AssumeRoleWithWebIdentity (for OIDC-based IdPs).

4. STS validates the token, ensuring that the user is authorized to assume the requested IAM role.

5. STS issues temporary security credentials, allowing the user to access AWS services.

---

Scenario 4: Service-to-Service Access Using AssumeRole

Use Case: An AWS service (e.g., Lambda, EC2, ECS) requires temporary access to another AWS service.

How STS is Involved

1. The service is assigned an IAM role with permissions to access another AWS service.

2. When the service runs, AWS automatically calls STS on its behalf to assume the IAM role.

3. STS generates temporary credentials that allow the service to interact with AWS resources.

4. AWS continuously rotates the temporary credentials without user intervention.

---

Scenario 5: MFA-Protected API Access with GetSessionToken

Use Case: An IAM user must use Multi-Factor Authentication (MFA) before performing certain AWS operations.

How STS is Involved

1. The user authenticates using their regular IAM credentials.

2. Before accessing sensitive resources, they must provide an MFA token.

3. The user calls STS GetSessionToken, passing their MFA token.

4. STS validates the MFA token and issues temporary credentials.

5. The user uses these credentials for AWS operations.

6. Once the session expires, the user must reauthenticate using MFA.

---

Scenario 6: Role Chaining (Assuming Multiple Roles)

Use Case: A user first assumes one IAM role, then assumes another role to gain different permissions.

How STS is Involved

1. The user or service first calls STS AssumeRole to get temporary credentials for Role A.

2. While using Role A, they call STS AssumeRole again to assume Role B.

3. STS issues new temporary credentials for Role B.

4. The user can continue chaining roles as long as IAM policies allow it.

5. Each assumed role has a separate expiration time, and session durations can be adjusted per IAM policy.

---

Summary of STS Involvement

Scenario	STS API Used
Cross-Account Access	sts:AssumeRole
AWS Identity Center (SSO) Login	sts:AssumeRole (Implicit)
Federated Access (SAML/OIDC)	sts:AssumeRoleWithSAML or sts:AssumeRoleWithWebIdentity
Service-to-Service Access	sts:AssumeRole (Automatic)
MFA-Protected API Calls	sts:GetSessionToken
Role Chaining	sts:AssumeRole (Multiple Times)

---

Key Takeaways

• STS is a core part of AWS security and plays a role in issuing temporary credentials for access control.

• STS works behind the scenes in AWS Identity Center (SSO), Federated Access, and Service-to-Service authentication.

• IAM roles do not authenticate users—STS is responsible for issuing credentials after authentication.

• Short-lived credentials improve security, reducing the risk associated with long-term IAM credentials.

• Cross-account access, role chaining, and MFA enforcement all rely on STS.