AWS STS use cases and advantages

I am confused about the use cases and advantages of STS. As per the documentation, it is to temporarily acquire a role to perform tasks within AWS which are not available for the IAM user or service. Please note that I am talking about programmatic access (NOT console access)

For example, an IAM user may not have S3 permissions. As per my understanding:

1. He can get temporary access key/token by contacting AWS STS and get access key and secret for S3.

2. With those temporary credentials, he can access S3.

My questions are:

1. To get temporary credentials from AWS STS, he still need his existing access token (permanent) and secret, right?

2. If his existing access token and secret are leaked, an attacker can still use it to first get temporary credentials from STS and then access S3, right? I understand that the attacker won't be able to directly access S3 using his permanent access token and secret.

I am trying to wrap my head around its correct use cases. I know that I'm confused, but maybe I'm thinking in loops.

Thanks in advance.

I will try to extend and generalise the first answer. The example with the Fire Warden is good to understand, but I feel it needs some extension.

Generally the AWS STS is able to return role credentials based on other identity or role credentials (aws or other identity provider).

The original credentials can be either AWS credentials from the same account, another account, federated token (e. g. supported social networks) or even a custom identity broker.

see https://docs.aws.amazon.com/cli/latest/reference/sts/index.html

Common use cases:

• privilege elevation - this is already mentioned, AssumeRole allows to become another role within the same or different aws account

• authorization to aws resources for identities authenticated a other way (AD, SAML, OIDC,..), see services AssumeRoleWithSAML or AssumeRoleWithWebIdentity.

• authorization to aws resources with custom authorization, see GetFederationToken.

To get temporary credentials from AWS STS, he still need his existing access token (permanent) and secret, right?

By default AssumeRole, the user needs to be authenticated and having permission to assume the role.

If his existing access token and secret are leaked, an attacker can still use it to first get temporary credentials from STS and then access S3, right?

yes

I understand that the attacker won't be able to directly access S3 using his permanent access token and secret

if you configure the S3 or IAM permissions that way