Temporary Credentials

Temporary credentials are short-lived AWS security credentials issued by the AWS Security Token Service (STS). They consist of an access key ID, a secret access key, and a session token, and they expire automatically after a configurable duration.

Unlike long-term access keys, temporary credentials cannot be leaked permanently: even if stolen, they expire. This is why AWS recommends using IAM roles (which use temporary credentials) instead of IAM users with long-term access keys for every use case possible.

How Temporary Credentials Are Issued

Every set of temporary credentials comes from one of the STS API operations, and each has its own duration rules:

• AssumeRole: the workhorse for cross-account access and privilege separation. Must be called with valid AWS credentials, and supports session policies, session tags, an external ID, and a source identity.
• AssumeRoleWithSAML: exchanges a SAML 2.0 assertion from your corporate identity provider for credentials. By default the resulting credentials expire after one hour.
• AssumeRoleWithWebIdentity: exchanges an OIDC JSON Web Token for credentials. This is what GitHub Actions and EKS pod identities use. The request is not signed and requires no existing AWS credentials, only a valid token.
• GetSessionToken: issues credentials to an existing IAM user, typically to add an MFA-authenticated session. Default duration is 12 hours, configurable from 900 seconds (15 minutes) up to 129,600 seconds (36 hours) for IAM users. For the root user, tokens are restricted to one hour.
• GetFederationToken: used by custom identity brokers, with durations between 15 minutes and 36 hours and a 12 hour default.

The session token is the piece that distinguishes temporary credentials from long-term keys. AWS validates it on every request, and its size is not fixed, so never assume a maximum length when storing it.

How It Goes Wrong in Practice

The classic failure pattern is credential exfiltration through the EC2 instance metadata service. An application running on an instance with an attached IAM role fetches its temporary credentials from the metadata endpoint. If that application has a server-side request forgery (SSRF) flaw and the instance still allows IMDSv1, an attacker can request the metadata URL through the vulnerable app, read the role credentials, and replay them from their own machine. The credentials are temporary, but a window of several hours is plenty of time to enumerate S3 buckets or spin up compute.

Two lessons follow. First, expiry limits damage, it does not prevent it: pair short sessions with detection and least-privilege role policies. Second, enforce IMDSv2 on your instances so that metadata requests require a session-oriented token, which blocks the simple SSRF pattern. Also remember that shortening session duration is a real control: a 15 minute session stolen in transit is worth far less to an attacker than a 12 hour one.

Practical Check: Request a Short MFA-Backed Session

You can see the mechanics yourself by requesting a short session token for an IAM user with MFA:

aws sts get-session-token --duration-seconds 900 --serial-number arn:aws:iam::123456789012:mfa/my-user --token-code 123456

The response contains AccessKeyId, SecretAccessKey, SessionToken, and an Expiration timestamp. Export all three values as environment variables and every subsequent CLI call runs under the temporary session. When the expiration passes, the same calls start failing with an expired token error, no revocation step needed.

Frequently Asked Questions

How long do temporary credentials last?

It depends on the API. GetSessionToken defaults to 12 hours and can run from 15 minutes to 36 hours for IAM users. Root user session tokens are capped at one hour. Role sessions obtained through AssumeRole respect the maximum session duration configured on the role itself, and SAML sessions default to one hour unless a longer duration is requested.

Can I revoke temporary credentials before they expire?

You cannot invalidate an issued session token directly. What you can do is change what the session is allowed to do: IAM evaluates the role's permissions policies on every request, so removing permissions from the role, or adding an explicit deny, takes effect immediately for all active sessions using that role.

Do temporary credentials behave differently from long-term keys in API calls?

Almost identically. The only mechanical difference is that requests must include the session token alongside the access key and secret key. AWS SDKs and the CLI handle this automatically, and SDK credential providers refresh sessions before they expire, which is why role-based workloads rarely need to think about it.