IAM
Advanced 14 min read IAM

Temporary Credentials and STS

Credentials with an expiry date

Static keys die; temporary credentials thrive. STS (or equivalent) issues short-lived, policy-scoped credentials with session limits — the backbone of roles, federation, and incident cut-offs.

STStemporary credentialssession tokenassume rolecredential rotation
Prerequisites: Roles and Policies
Before we start

What you will learn

  • Explain STS short-lived credentials
  • Use assume-role and session policies
  • Design incident cut-off with temporary + deny
In 60 seconds

STS issues access/secret/session tokens valid for up to 12h (AWS) or hours for Azure/GCP, bound to a role's policies plus an optional session policy. Temporary = auto-expiry, tiny blast radius when leaked.

Introduction

What is this?

AWS STS (Security Token Service): sts:AssumeRole, AssumeRoleWithWebIdentity, GetFederationToken. Credentials carry an expiry (default 1h, up to 12h/role maximum), a session name, an optional session policy (further scoping), and tags for IAM-based conditions. Azure AD/orar tokens are short-lived with access-token expiry; GCP short-lived service account tokens (create-access-token up to 1h). Temporary creds mean compromise windows are bounded and rotation is automatic — static keys become the exception.

Motivation

Why do you need it?

  • A leaked 60-minute token is a hiccup; a leaked static key is a breach.
  • Session policies let you scope on the fly (e.g. read-only for an incident responder).
  • STS is what makes cross-account and OIDC flows possible.
  • Regulators prefer time-boxed credential use.
Think about it

Mental model

Imagine

A hotel key card that stops working at checkout

Think of

Temporary credentials

You get a card good for your stay (session), scoped to your room floor. At checkout it dies. No one needs to manually shred the card — expiry did the work.

Mechanics

How it works

  • Call sts:AssumeRole with role ARN + session name → temporary keys with expiry.
  • Optionally pass a session policy (SessionPolicy) narrowing what the session may do.
  • Cross-account: the assuming principal needs sts:AssumeRole permission + trust allows on the role.
  • OIDC/SAML: sts:AssumeRoleWithWebIdentity/WithSAML via trust claims
  • Azure/GCP equivalents: short-lived bearer tokens with scopes.

STS credential lifecycle.

Principal calls AssumeRole
STS issues token
Session policy applied
Workload uses it
Expiry
Hands-on

Examples

Assume a scoped session

Assume a scoped session
# Read-only assumptions for incident response
aws sts assume-role --role-arn arn:aws:iam::991100000000:role/IncidentReader \
  --role-session-name oncall-$(date +%s) --duration-seconds 3600 \
  --policy-arns 'arn=arn:aws:iam::aws:policy/ReadOnlyAccess'
 
# Use the printed keys in this shell
export AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=... AWS_SESSION_TOKEN=...

The session gets ReadOnlyAccess and dies in an hour — no standing prod keys for the night shift.

Real world

In production

  • Incident responders assume a scoped read-only role with a 1h TTL.
  • CI OIDC flows mint 15-minute tokens for deploys.
  • Cross-account analysts assume behalf-of provenance roles with session tags for IAM conditions.
Guidelines

Best practices

  • Default to temporary credentials for anything that can use them.
  • Use session names + tags for audit granularity (who/what/why).
  • Add session policies for ad-hoc scoping rather than spinning new roles.
  • Set duration-seconds to the smallest window that allows work to finish.
Watch out

Common mistakes

  • Storing STS output and treating it like static keys (still fine, but remember expiry).
  • Failing to scope a session policy, so the role's breadth applies unchanged.
  • Long duration-seconds 'just in case' — shorter is better for an incident.
  • Relying on manually rotated static keys where STS would do.
Root cause analysis

Common issues

Error
sts:AssumeRole denied for a user with the AssumeRole allow
Root cause

Role's trust policy doesn't include the user, or a condition fails

Fix

Adjust the role's trust policy and re-check conditions (MFA, source IP, OIDC sub).

Error
Session fails mid-way with ExpiredToken
Root cause

duration-seconds elapsed

Fix

Increase duration or re-assume; prefer workflow refresh over long tokens.

When things break

Debugging tips

  • Expired creds → SDK error 'ExpiredToken' — check session duration, not just trust.
  • For assumed roles, audit session name/tags in CloudTrail for who assumed.
  • Cross-account assumption requires BOTH trust (target) and permission (source).
  • Time skew: temporary tokens fail early/late if the client clock drifts.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/1
1

What limits what an assumed STS session can do beyond the role's policies?

Go deeper

Official documentation

AWS — STS
docs
GCP — Short-lived credentials
docs