STS and Temporary Credentials

Yuki's team needed to give a partner company read access to one S3 bucket for a two-week joint project. The wrong answer is "create them an IAM user and send the keys over Slack." The right answer involves a service most developers underuse: AWS Security Token Service (STS).

STS is the engine behind almost every modern AWS authentication pattern. Once you understand it, IAM stops feeling like magic.

What STS Does

AWS STS issues short-lived credentials — typically valid for 15 minutes to 12 hours — in exchange for some form of proof of identity. A successful STS call returns three things:

• An Access Key ID;
• A Secret Access Key;
• A session token — the piece that says "these are temporary." After expiry, the credentials simply stop working. Even if leaked, the blast radius has a deadline.

The Key STS Actions

Five STS calls cover almost everything:

• AssumeRole — swap into a different IAM role, possibly in a different account;
• AssumeRoleWithSAML — assume a role using a SAML assertion from a corporate identity provider;
• AssumeRoleWithWebIdentity — assume a role using a JWT from Cognito, Google, Facebook, or any OIDC provider;
• GetSessionToken — get short-lived credentials for the calling IAM user, often used to enforce MFA;
• GetFederationToken — issue credentials for a user managed outside IAM, for older federation setups. For Yuki's partner scenario, the cleanest pattern is: create an IAM role in her account with read access to the bucket, and let the partner's account assume it. No user, no key handoff.

How AssumeRole Works

The flow has four steps:

• The caller (a user or another role) calls sts:AssumeRole against a target role;
• STS checks the target role's trust policy — does it allow this caller?;
• STS checks the caller's identity policy — is the caller allowed to call AssumeRole?;
• If both pass, STS returns temporary credentials scoped to the target role. The trust policy is the gate. A role with no trust policy can never be assumed by anyone.

Cross-Account Access In Practice

Cross-account access is the everyday use case. Setup:

• Account A creates a role with a trust policy that says "Account B can assume me";
• Account B grants its users sts:AssumeRole permission against that specific role ARN;
• A user in Account B runs aws sts assume-role --role-arn arn:aws:iam::A:role/ReadOnly and gets credentials for Account A. No keys cross accounts. No long-lived users in Account A. Revocation is immediate — Account A just removes the role.

Web Identity Federation

For mobile and web apps, AssumeRoleWithWebIdentity is the workhorse. The user logs in with Google or Cognito, the app gets an ID token, the app trades that token to STS for AWS credentials, and the user can now read their own S3 objects directly — no server in between.

This is how serverless apps avoid having a backend just to proxy AWS calls.

When to Use What

A simple decision rule:

• Application running on EC2, Lambda, or ECS → attach a role, SDK gets credentials automatically;
• Cross-account access between AWS accounts → AssumeRole;
• Corporate SSO users logging into AWS → AssumeRoleWithSAML or IAM Identity Center;
• Mobile or web app users → AssumeRoleWithWebIdentity, often through Cognito Identity Pools;
• A human needing temporary credentials with MFA → GetSessionToken. If a question on the exam mentions "temporary credentials" or "cross-account" or "federation," STS is somewhere in the answer.