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:

The IAM user or service in Account A requests temporary credentials by calling sts:AssumeRole for a role in Account B.
STS validates the trust policy on the target IAM role and issues temporary credentials.
The IAM user or service uses these credentials to access AWS resources in Account B.
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:

The user authenticates via AWS Identity Center, which may be backed by an external Identity Provider (IdP) such as Okta, Active Directory, or Google.
Based on configured permission sets, Identity Center determines which IAM roles the user can assume.
AWS Identity Center automatically calls STS to assume the role and retrieve temporary credentials.
The user gains access to AWS resources using the credentials issued by STS.
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:

The user logs into the external IdP, which authenticates their identity.
The IdP generates a SAML assertion or OIDC token that the user presents to AWS.
The user calls STS AssumeRoleWithSAML (for SAML-based IdPs) or STS AssumeRoleWithWebIdentity (for OIDC-based IdPs).
STS validates the token, ensuring that the user is authorized to assume the requested IAM role.
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:

The service is assigned an IAM role with permissions to access another AWS service.
When the service runs, AWS automatically calls STS on its behalf to assume the IAM role.
STS generates temporary credentials that allow the service to interact with AWS resources.
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:

The user authenticates using their regular IAM credentials.
Before accessing sensitive resources, they must provide an MFA token.
The user calls STS GetSessionToken, passing their MFA token.
STS validates the MFA token and issues temporary credentials.
The user uses these credentials for AWS operations.
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:

The user or service first calls STS AssumeRole to get temporary credentials for Role A.
While using Role A, they call STS AssumeRole again to assume Role B.
STS issues new temporary credentials for Role B.
The user can continue chaining roles as long as IAM policies allow it.
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

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

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.

Last updated 1 year ago