Q&A

How do AWS Security Token Service (STS) keys work?

By AlgoInsight Team2026-06-07awscloud-computingsecurity

Overview

Long-lived access keys (tied to IAM users) are a security liability: if leaked, they work until manually revoked. AWS STS solves this by minting temporary credentials on demand. They consist of three parts and automatically expire, so even a leaked set becomes useless quickly. STS underpins role assumption, cross-account access, and identity federation.

graph TD
    A[Principal needs AWS access] --> B[Call STS: AssumeRole / GetSessionToken]
    B --> C[STS returns 3 parts:<br/>AccessKeyId + SecretAccessKey + SessionToken]
    C --> D[Use them to sign API requests]
    D --> E[Credentials EXPIRE automatically]
    style C fill:#1e1b4b,color:#fff

The Three Parts of STS Credentials

Unlike permanent IAM keys (two parts), STS credentials have three:

1. Access Key ID - identifies the credentials (like a username).
2. Secret Access Key - used to sign requests (like a password).
3. Session Token - a token that must accompany every request; it's what makes the credentials temporary and is validated by AWS.

All three are required; omitting the session token causes authentication failure.

Key STS Operations

How AssumeRole Works (the common flow)

1. A principal (user, service, EC2 instance, Lambda) calls sts:AssumeRole,
   naming the target role's ARN.
2. AWS checks the role's trust policy (who is allowed to assume it) and the
   caller's permission to assume it.
3. STS returns temporary credentials scoped to that role's permissions,
   valid for the requested duration (default 1 hour, up to the role's max).
4. The principal signs subsequent API calls with these temporary creds.
5. When they expire, the principal assumes the role again for fresh creds.

Example (AWS CLI)

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/MyRole \
  --role-session-name my-session
# returns AccessKeyId, SecretAccessKey, SessionToken, and Expiration

Why Temporary Credentials Are Better

• Auto-expiry - leaked credentials are useless after they expire (minutes/hours), unlike permanent keys that work until revoked.
• No stored secrets - EC2 instances, ECS tasks, and Lambda functions get credentials automatically via roles (e.g. instance profiles / the metadata service), so you never embed keys in code or config.
• Least privilege & scoping - assumed-role credentials carry only that role's permissions; you can further restrict with session policies.
• Federation - external identities (corporate SSO, web/OIDC) can get AWS access without an IAM user each.

Duration and Expiration

Default session duration is typically 1 hour; AssumeRole supports 15 minutes up to the role's configured maximum (up to 12 hours). Applications should detect expiry and refresh by re-calling STS (the AWS SDKs handle this automatically when using roles).

Best Practices

• Prefer roles + STS over long-lived IAM user keys everywhere possible.
• Use instance profiles / task roles / Lambda execution roles so workloads get temporary creds automatically - never hard-code keys.
• Require MFA for sensitive GetSessionToken/AssumeRole calls.
• Apply least privilege and short durations.

Why This Matters in Interviews

AWS/security interviews use STS to test cloud-security maturity. The headline points: STS issues temporary credentials with three parts (the extra session token), they expire automatically (reducing leak risk), and AssumeRole is the core mechanism for cross-account access and federation. The strongest signal is articulating why temporary, role-based credentials beat long-lived IAM keys, and that workloads should obtain them via roles rather than embedding secrets.

Common Pitfalls

• Forgetting the session token is required (STS creds have three parts, not two).
• Treating STS credentials as permanent and not handling expiry/refresh.
• Embedding long-lived IAM keys in code instead of using roles + STS.
• Over-broad role permissions, defeating least privilege.
• Confusing the role's trust policy (who can assume it) with its permissions policy (what it can do).

References

• AWS STS documentation: https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html
• IAM temporary security credentials: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html

More answers