> For the complete documentation index, see [llms.txt](https://awsinpractice.itassist.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://awsinpractice.itassist.com/study-group/aws-certified-solutions-architect-associate/domain-1-design-secure-architectures/copy-of-task-statement-1.1-design-secure-access-to-aws-resources/copy-of-aws-security-token-service-sts.md).

# Copy of AWS Security Token Service (STS)

AWS Security Token Service (STS) is a global AWS service that **issues temporary security credentials** for IAM users, federated users, and AWS services. These credentials allow access to AWS resources based on IAM policies without requiring long-term credentials.

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**.

### **🔹 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.

##

## **Temporary Credentials in AWS**

### **What Are Temporary Credentials?**

Temporary credentials provide short-lived, automatically expiring access to AWS services, eliminating the need for long-term IAM User credentials.

**AWS Services that Provide Temporary Credentials:**

* **IAM Roles** → Assigned to AWS services (EC2, Lambda, ECS) for automatic access.
* **AWS STS (Security Token Service)** → Issues temporary credentials for cross-account access.
* **IAM Identity Center (SSO)** → Grants temporary AWS access to users through permission sets.

***

### **How Temporary Credentials Work in AWS**

#### **Scenario: SecureCart’s EC2 Instance Accessing S3 Using IAM Role**

**Requirement:** SecureCart’s EC2 instances need to retrieve product images from an S3 bucket without using hardcoded credentials.

**Solution**

* Create an IAM Role and attach it to the EC2 instance.
* The IAM Role allows `s3:GetObject` permission for the `securecart-product-images` bucket.
* EC2 retrieves temporary credentials automatically when accessing S3.

***

## **Temporary Credentials Use Case: SecureCart Applications**

SecureCart **never stores long-term AWS credentials** in applications. Instead, it **uses IAM Roles and AWS STS** to issue **temporary credentials**.

**Example: SecureCart’s EC2 Instance IAM Role**

```json
jsonCopyEdit{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "secretsmanager:GetSecretValue"
      ],
      "Resource": [
        "arn:aws:s3:::securecart-invoices/*",
        "arn:aws:secretsmanager:us-east-1:123456789012:secret:DBPassword"
      ]
    }
  ]
}
```

**Impact:**

\
**SecureCart’s EC2 instances automatically get temporary credentials** to access S3 and Secrets Manager **without storing access keys**.

***

## **AWS STS Use Case: Granting Temporary Access to Third-Party Auditors**

SecureCart occasionally allows **external auditors** to review security logs. Instead of creating IAM Users, SecureCart **uses AWS STS AssumeRole to issue temporary credentials**.

✅ **Example: Allowing Auditors Temporary Read-Only Access**

```json
jsonCopyEdit{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::987654321098:root"
      },
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::123456789012:role/SecureCart-AuditRole"
    }
  ]
}
```

**Impact:**

\
✅ **Auditors receive temporary credentials valid for a limited time (e.g., 1 hour).**\
✅ **They cannot assume roles beyond the permissions granted in `SecureCart-AuditRole`.**

##

***

## **SecureCart Use Case: Role-Based Access Control (RBAC) and Temporary Credentials**

### **Business Context**

SecureCart is an **e-commerce platform** that requires **secure access control** to AWS resources for developers, operations teams, and applications. Instead of using IAM Users with long-term credentials, SecureCart **implements Role-Based Access Control (RBAC) using IAM Roles and temporary credentials.**

***

### **Security Challenges for SecureCart**

🔹 **Ensure least privilege access** for different teams and services.\
🔹 **Avoid hardcoded credentials** in applications.\
🔹 **Prevent unauthorized access to production environments.**\
🔹 **Implement temporary access for automation and external integrations.**

***