What is AWS STS?

Definition

AWS Security Token Service (STS) is the AWS service that issues temporary, limited-privilege credentials for IAM principals. STS underpins role assumption, federation, cross-account access, and EC2 / Lambda / ECS / EKS service identity.

The credentials STS returns expire automatically (typically 15 minutes – 12 hours), eliminating the long-lived credential risks of static IAM access keys.

In simple terms:

STS hands out short-lived AWS keys whenever an allowed principal asks. It's the engine behind every modern AWS access pattern that doesn't use long-lived keys.

---

Why STS Matters

• Eliminates long-lived credentials for most use cases.
• Powers role assumption — the foundation of secure cross-account access.
• Enables federation from external identity providers without storing passwords or keys in AWS.
• Provides session policies to further restrict permissions.
• Forms the credentials backbone for IAM Identity Center, IRSA, IAM Roles for Tasks, etc.

---

STS APIs

sts:AssumeRole

Assume an IAM role from another AWS principal (user, role, or service).

aws sts assume-role \
  --role-arn arn:aws:iam::123:role/MyRole \
  --role-session-name session1

sts:AssumeRoleWithSAML

Assume a role using a SAML 2.0 assertion from a federated IdP.

sts:AssumeRoleWithWebIdentity

Assume a role using an OIDC token (GitHub Actions, Cognito, Kubernetes ServiceAccount, etc.).

sts:GetSessionToken

Get temporary credentials for an existing IAM user, often with MFA.

sts:GetCallerIdentity

Return information about the current caller. Useful for diagnostics; doesn't grant anything.

sts:GetFederationToken

(Legacy) get temporary credentials with a custom session policy.

---

Typical Patterns

EC2 Instance Profile

EC2 instance is assigned an instance profile referencing an IAM role. SDKs read temporary credentials from IMDSv2; AWS handles refresh automatically.

Lambda Execution Role

Lambda function is assigned an execution role; the runtime presents temporary credentials to your code.

ECS Task Role / EKS IRSA

Container tasks get scoped temporary credentials per task instead of sharing instance role.

CI/CD via OIDC

GitHub Actions / GitLab presents an OIDC token; AWS validates and returns role-scoped temporary credentials. No stored secrets.

Cross-Account Auditor

Auditor in account A assumes role in account B; gets temporary credentials valid only for that audit work.

IAM Identity Center

When users SSO into AWS console or CLI, Identity Center calls AssumeRole behind the scenes; user gets temporary credentials per Permission Set.

---

Credentials Returned by STS

{
  "Credentials": {
    "AccessKeyId": "ASIA...",
    "SecretAccessKey": "...",
    "SessionToken": "...",
    "Expiration": "2026-05-02T11:00:00Z"
  },
  "AssumedRoleUser": {
    "AssumedRoleId": "AROA...:session1",
    "Arn": "arn:aws:sts::123:assumed-role/MyRole/session1"
  }
}

Note the SessionToken — required for SDK calls when using temporary credentials.

---

Session Duration

• Default: 1 hour for AssumeRole.
• Configurable per role: 15 min – 12 h (for direct role calls).
• Chained role calls capped at 1 hour.
• Federation tokens up to 12 h.

Shorter is more secure (smaller window for stolen credentials), but too-short can cause UX friction. 1–4 hours is a common balance.

---

Session Policies

When assuming a role, you can pass a session policy that further restricts permissions for the resulting session — never expanding beyond the role's policies.

Useful for delegating the role with reduced scope per session.

---

Common Risks

• Long session durations (12 h) widening credential leak window.
• Trust policies allowing too-broad principals.
• No external ID in third-party cross-account.
• No condition checks on service trust (Confused Deputy).
• Token theft from EC2 IMDSv1 (Capital One pattern).
• OIDC trust misconfiguration allowing wrong GitHub repos to assume your role.
• Chained assume-role without monitoring.
• Session credentials persisting in shells / files / logs.

---

Real-World Examples

1. Capital One via IMDSv1

EC2 metadata service (v1) was hit via SSRF to steal the instance role's STS credentials. Attacker used them to read S3.

Mitigation: Enforce IMDSv2 on all EC2; least-privilege instance roles.

2. GitHub Actions OIDC (No Secrets)

Move from stored AWS access keys in GitHub Secrets → OIDC trust to a role. GitHub presents short-lived OIDC token; STS issues short-lived AWS credentials. No long-lived secrets anywhere.

3. SOC Read Across Accounts

Auditor switch-roles into each member account via federation; temporary credentials per session; full CloudTrail visibility.

4. Confused Deputy Mitigation

Service role for Backup added aws:SourceArn and aws:SourceAccount conditions, preventing other accounts' Backup from triggering this role.

---

STS Best Practices

1. Prefer STS-based patterns (roles, federation, IRSA, IAM Identity Center) over long-lived keys.
2. Enforce IMDSv2 on EC2.
3. Short session durations by default; extend only with reason.
4. Tight trust policies with conditions.
5. External ID for third-party cross-account.
6. aws:SourceArn / aws:SourceAccount conditions on service trust.
7. OIDC trust restricted to specific repos/branches/environments.
8. Detect unusual AssumeRole events (new principals, new IPs).
9. Use session tags for ABAC.
10. Centralize logs of STS calls in CloudTrail and SIEM.
11. Avoid chained assume-role unless justified.

---

STS Checklist

• Long-lived access keys minimized via STS-based patterns?
• IMDSv2 enforced for EC2?
• OIDC federation for CI/CD instead of stored keys?
• Trust policies tight; conditions used?
• External IDs for third-party trust?
• Session durations appropriate?
• CloudTrail logging of STS events centralized?
• Detection on anomalous AssumeRole?

---

How Forestall Helps

Forestall analyzes the STS-driven access graph:

• Trust relationships across accounts.
• IRSA / OIDC / SAML federation paths.
• Risky trust policies (broad principals, missing conditions).
• Excessive session durations.
• Long-lived credentials that could be replaced by STS-based patterns.

---

Frequently Asked Questions

Is STS free?

Yes — no charge for STS API calls.

Where is STS available?

In every AWS region; the default sts.amazonaws.com global endpoint redirects, but regional endpoints (sts.<region>.amazonaws.com) are recommended for performance and resilience.

Can I use STS without IAM?

No — STS issues credentials for IAM principals. IAM defines roles and trust; STS issues sessions.

Do temporary credentials expire mid-call?

If a credential expires before SDK refresh, the call fails. SDKs typically refresh automatically before expiration.

What happens if I lose a session token?

It expires soon anyway. Treat any leaked credentials as compromised — revoke (if possible) and rotate the underlying access path.

---

Conclusion

AWS STS is the engine behind every modern AWS identity pattern. Use it (via roles, federation, IRSA, IAM Identity Center, OIDC) to eliminate long-lived credentials, narrow blast radius, and improve auditability. Combined with tight trust policies, MFA conditions, IMDSv2, and continuous monitoring, STS is the way most AWS access should happen — and most credential-leak risk goes away when it does.