Temporary Credentials

Temporary credentials are valid for a bounded period rather than until someone explicitly disables or replaces them. An identity service issues them after authenticating a person, validating a federated identity, or establishing that a workload can assume a role. Their permissions determine what the session can do, while their expiration determines how long the credentials remain usable. Short lifetimes reduce exposure after theft, but do not prevent misuse during an active session.

In AWS, temporary API credentials issued by AWS Security Token Service consist of an access key ID, a secret access key, and a session token, together with an expiration time. Requests must include the session token as well as use the key pair for authentication. A missing token can cause authentication failures even when the access key ID and secret access key are correct. Temporary credentials are still secrets: never put them in source code, container images, logs, or public build artifacts.

For human access, federation allows users to authenticate through an identity provider and obtain temporary access instead of receiving individual long-term IAM access keys. IAM Identity Center provides workforce access to AWS accounts through permission sets and role sessions. Multi-factor authentication strengthens authentication, but it is not itself a permission grant or a substitute for temporary credentials. Enforce MFA through the appropriate identity-provider or AWS policy controls rather than assuming that every temporary session proves MFA occurred.

Cross-account access commonly uses role assumption. For example, an engineer authenticated in a development account can assume a troubleshooting role in a production account without creating another IAM user there. The target role's trust policy controls who can assume it, while its permissions policies define allowed actions. Cross-account role assumption normally requires authorization in the caller's account and trust in the target account. Session policies can further restrict access; they cannot expand the role's permissions. Other applicable controls, including explicit denies and organization policies, still apply.

Compute workloads should receive credentials through workload roles. On Amazon EC2, an instance profile associates an IAM role with an instance, and applications can obtain temporary credentials through instance metadata. Require IMDSv2 and restrict metadata access appropriately to reduce credential-exposure risk. AWS Lambda supplies credentials for its execution role to function code. Amazon ECS applications use task roles; the task execution role instead authorizes actions performed by the ECS agent, such as retrieving images or configured secrets. More generally, a service role authorizes an AWS service to act on your behalf, while an execution role supplies the permissions required for a particular workload or execution context.

Supported SDK credential providers retrieve and refresh workload credentials automatically when configured correctly. Applications that manually copy credentials into environment variables or cache them indefinitely can fail when the session expires. Troubleshooting should distinguish expired credentials, missing session tokens, incorrect trust policies, insufficient permissions, clock skew, and a credential provider selecting unintended static keys. Shorter sessions reduce exposure but increase renewal activity and dependence on the credential-issuing path.

Temporary credential renewal differs from secret rotation. AWS Secrets Manager can store application secrets and coordinate supported rotation workflows, such as changing a database password and updating the stored value. Merely storing a long-term IAM access key in a secret does not make it temporary or automatically rotate it. Prefer roles for AWS API access, and use managed secret storage and rotation for credentials that the target system still requires. If temporary credentials are compromised, stop unauthorized issuance and apply appropriate session-revocation or explicit-deny controls; do not assume that disabling the original login invalidates every existing session. Audit role assumptions and subsequent API activity to connect resource access to the responsible person or workload.