Learn how AWS Security Token Service issues temporary credentials, how AssumeRole works, how role chaining and session policies affect access, and what a security researcher should verify before reporting an IAM weakness.

============================================================

WHY STS MATTERS IN AWS SECURITY ============================================================

AWS Security Token Service (AWS STS) issues temporary security credentials for identities that need to access AWS resources. Rather than distributing a long-lived access key for every task, an application, user, workload, or federated identity can obtain credentials for a limited session.

The AssumeRole API is one of the main ways to obtain a role session. The caller makes an authenticated request to STS, AWS evaluates whether the caller is permitted to assume the target role and whether the role's trust policy accepts that principal, and STS returns temporary credentials if the request succeeds.

Those credentials can then be used to make AWS API requests as the assumed role, subject to the effective permissions of the session and the authorization controls that apply to each request.

For security research, this introduces several separate questions:

Can the current identity call the relevant STS operation?
Does the target role trust the caller under the request's conditions?
What permissions will the resulting role session have?
How long will the credentials remain valid?
Can the session assume another role?
Can the activity be attributed and detected?
Is the access intended, authorized, and demonstrably impactful?

Finding a role ARN does not prove that it can be assumed. Finding an AssumeRole permission does not by itself prove that a particular role's trust policy accepts the caller. And successfully assuming a role does not automatically mean the session has administrator access.

============================================================ 2. WHAT ARE TEMPORARY SECURITY CREDENTIALS?

AWS STS credentials include three pieces:

Access key ID
Secret access key
Session token

The session token is required when making requests with these temporary credentials. AWS SDKs and the AWS CLI can handle signing requests and including the required token when configured with the temporary credentials.

Temporary credentials have an expiration time. After they expire, AWS rejects requests made with them. A workload or user may obtain a new session if it remains authorized to do so, but the original credentials do not simply extend themselves beyond their requested lifetime.

Temporary credentials are useful because they reduce the need to distribute long-term keys and support role-based access, federation, and workload identities. They are not automatically safe, however. If an attacker obtains valid temporary credentials, they may be able to use them until they expire or until the effective access is otherwise restricted. The actual impact depends on the permissions, conditions, resources, and remaining controls.

Security lesson: temporary describes the credential lifetime, not the sensitivity of the access. A 15-minute session with permission to modify a critical resource can still have serious consequences.

============================================================ 3. HOW ASSUMEROLE WORKS

A simplified AssumeRole flow looks like this:

A caller already has valid AWS credentials or an accepted federated identity flow.
The caller requests a session for a specific IAM role, identified by its ARN.
AWS evaluates the relevant permission and trust relationship, including applicable conditions.
If the request is authorized, STS returns temporary credentials and session metadata.
The caller uses those credentials to make AWS API requests as the assumed role.
AWS evaluates permissions for each subsequent request in its own authorization context.

The target role's trust policy controls which principals may assume it. The role's permissions policies describe what the role can do. These are related but distinct decisions, as explained in Article 11.

For cross-account access, authorization must work across the account boundary. The trusting account's role must accept the relevant principal, and the caller must have the required authorization to request the role session. Organization policies, explicit denies, conditions, and other controls can also affect the result. Do not reduce cross-account authorization to a single Allow statement viewed in isolation.

The main API for this flow is sts:AssumeRole. Other federation flows use different STS operations, such as AssumeRoleWithSAML and AssumeRoleWithWebIdentity. They are related but not interchangeable; the authentication material and trust configuration differ by flow.

============================================================ 4. ROLE SESSION DURATION: THE IMPORTANT LIMITS

For AssumeRole, the default session duration is one hour. The requested duration can generally range from 900 seconds (15 minutes) up to the role's configured maximum session duration, which can be set from one to twelve hours. A request that exceeds the applicable maximum fails.

Role chaining has a stricter limit: when a caller uses one assumed role session to assume another role, the chained session is limited to a maximum of one hour. Requesting more than one hour for a chained AssumeRole session fails, even if the target role's configured maximum is longer.

These details matter during reviews. A configured role maximum of twelve hours does not mean every session can last twelve hours. The calling context and whether role chaining is involved affect the applicable limit.

A shorter duration can reduce the window in which stolen credentials remain usable, but it does not fix excessive permissions or an overly broad trust policy. Session duration is one control, not a substitute for least privilege.

============================================================ 5. SESSION POLICIES: RESTRICTING A ROLE SESSION

An AssumeRole request can optionally include a session policy. A session policy limits permissions that the resulting session can receive from the role's identity-based policies; it does not grant permissions that the role itself does not have. For those permissions, the effective set is generally the intersection of the role's identity-based permissions and the session policy. Resource-based policies can also affect access, and the principal named in a resource policy matters: in some same-account cases, a policy that grants access directly to a role-session ARN can grant permissions that are not limited by an implicit deny in the session policy. Do not treat the intersection model as a complete description of every resource-policy case.

Session policies can be useful when a trusted caller needs only a narrower subset of a role's permissions for a particular task. They should not be treated as the only safeguard: role permissions, trust policy, resource policies, explicit denies, permissions boundaries, service control policies, resource control policies where applicable, and request conditions may all matter to the final decision. AWS's policy-evaluation guidance distinguishes a resource policy that names the role ARN from one that names the assumed-role session ARN; that distinction can change how session policies and permissions boundaries affect access.

When reviewing a system, do not assume that a session policy is present just because the role is assumed, and do not assume that an absent session policy makes the session unrestricted. The role's own permissions and other applicable controls still matter.

============================================================ 6. ROLE CHAINING AND WHY IT DESERVES ATTENTION

Role chaining means using credentials from one assumed role session to assume another role. For example, a deployment identity may assume a build role, which is then authorized to assume a narrowly scoped release role.

Role chaining is a legitimate design pattern, but each link introduces another trust and authorization relationship to understand. A security review should establish:

Which identity starts the chain?
Which role can it assume first?
Which permissions are available in the first session?
Does that session have the authority to call AssumeRole for the next role?
Does the next role trust the first role session or its principal in the expected way?
Are conditions, session tags, and source identity handled as intended?
What resources can the final session access?
Is the chain necessary, and can any link be narrowed?

A chain is not proof of privilege escalation by itself. To demonstrate a meaningful security issue, identify the initial authorized capability, the specific weak relationship or permission, the new capability gained, and the impact on a resource or security boundary.

Remember the one-hour maximum for chained role sessions. Also review session tags when they are used for attribute-based access control (ABAC). Session tags can influence policy evaluation through keys such as aws:PrincipalTag; transitive tags may persist through role chaining. If tag values influence access, verify who is allowed to pass them and which trust-policy conditions constrain them.

============================================================ 7. EXTERNAL IDs, SOURCE IDENTITY, AND SESSION NAMES

Three request attributes are worth distinguishing:

External ID

An external ID can be required when a third-party principal assumes a role, often to help address the confused deputy problem. It is a value agreed between the customer and the third party and checked through the role trust configuration. It is not a password or a general-purpose secret, and its presence alone does not make an overly broad trust policy safe.

Source identity

Source identity can help identify the original identity associated with a role session and support traceability through role chaining. A trust policy can require source identity using the relevant STS condition key. Review how the value is set, preserved, and recorded rather than treating any arbitrary value as proof of a person's identity.

Role session name

The role session name identifies a particular session and appears in the assumed-role ARN and relevant logs. It is useful operational context, but a name supplied by a caller is not, by itself, strong proof of who operated the session.

For each attribute, ask whether the organization requires it where appropriate, whether policy conditions validate it, and whether monitoring uses it meaningfully. Avoid confusing identification metadata with authorization.

============================================================ 8. AUTHORIZED AWS CLI ENUMERATION

The following commands are intended for an AWS account and identity you own or are explicitly authorized to assess. They are read-oriented discovery and identity checks; they do not attempt to assume arbitrary roles.

A. Identify the active caller

aws sts get-caller-identity

What it does: returns the account and identity ARN associated with the credentials currently being used.

Why it matters: it establishes the starting principal for a review. Do not assume the configured profile, account, or role is the one actually active until you verify it.

What to look for: the account ID and ARN, including whether the ARN represents an IAM user or an assumed role session. Do not paste real account identifiers or credentials into public reports.

B. Inspect a role's trust policy and configuration

aws iam get-role — role-name ExampleRole

What it does: retrieves role metadata, including the trust policy and the role's configured maximum session duration.

Why it matters: the trust policy helps answer who may assume the role and under which conditions. The maximum session duration provides context for evaluating requested session lengths.

What to look for: trusted principals, the sts:AssumeRole action, conditions, and whether the trust matches the documented design. A trust statement alone does not establish that a particular caller can successfully assume the role; consider the full authorization context.

C. Inspect attached managed policies

aws iam list-attached-role-policies — role-name ExampleRole

What it does: lists managed policies attached to the role.

Why it matters: it identifies policy documents that should be reviewed to understand the role's intended access.

What to look for: broad actions, broad resources, privilege-management permissions, and policy names that require follow-up. A policy name is not a substitute for reading the policy document.

D. Inspect inline policy names

aws iam list-role-policies — role-name ExampleRole

What it does: lists inline policies embedded in the role.

Why it matters: a role's permissions may come from attached managed policies, inline policies, or both.

What to look for: policy names and whether each needs to be retrieved and reviewed. If a name is returned, inspect the relevant document with:

aws iam get-role-policy — role-name ExampleRole — policy-name ExampleInlinePolicy

E. Check the current session after a legitimate role assumption

aws sts get-caller-identity

Run this again after an authorized role assumption, using the credentials for that session. Compare the returned ARN and account with the expected role and account. This confirms the identity represented by the credentials currently in use; it does not independently prove every permission the session has.

CLI behavior and access to each operation depend on the caller's permissions and environment. Commands may return AccessDenied or other errors. Such an error is evidence about that request in that context, not universal proof that the resource or permission does not exist.

No command output is included here because no live AWS account was used to validate these examples. Output should be captured and described only when it has actually been observed in an authorized environment.

============================================================ 9. HOW TO ASSESS AN ASSUMEROLE FINDING

Suppose an assessment discovers a role named ReleaseOperator. Its trust policy accepts a principal from another account, and the role's permissions allow certain deployment operations.

A weak report might say: "The role trusts another account, so it is vulnerable."

That conclusion is not supported by the trust relationship alone. Cross-account role access can be an intended administrative or deployment design.

A stronger assessment asks:

Is the external principal expected and controlled?
Which exact principals can satisfy the trust policy?
Are conditions, such as external ID or organization restrictions, present where the design requires them?
Can the starting identity actually make the AssumeRole request under the applicable authorization controls?
What permissions does the resulting session effectively have?
Can the session perform a sensitive action, and what resource would be affected?
Are there explicit denies or other controls that change the result?
What evidence proves the access path without exceeding the assessment's authorization?
What logs and detections would help identify misuse?

If no successful assumption or meaningful downstream access has been demonstrated, describe the evidence precisely. A discovered role, a trust relationship, a permission, a successful role assumption, and a demonstrated impact are different levels of evidence.

============================================================ 10. DETECTION AND DEFENSIVE REVIEW

CloudTrail records authenticated IAM and STS API requests, including role-assumption activity. Review events such as AssumeRole in the context of the calling identity, target role, account, source information, requested session details, and the actions that follow. Cross-account investigations may require examining records in more than one account: the target role's account can record a successful cross-account assumption, while subsequent API actions are recorded in the accounts where those actions occur. Important limitation: AWS documents that denied STS requests for cross-account role assumptions are not logged in the target account, so absence of a target-account event does not prove that no attempt occurred.

Useful defensive practices include:

Keep trust policies limited to the principals that need access.
Use conditions appropriate to the integration, such as external IDs for third-party access or organization restrictions where supported and suitable.
Grant the role only the actions and resources required for its purpose.
Require and preserve source identity where it supports accountability.
Review session tags carefully when tags drive ABAC decisions.
Keep session duration appropriate to the workload, remembering the separate role-chaining limit.
Monitor unusual role assumptions and sensitive API activity after assumption.
Remove obsolete cross-account relationships and unused roles.
Reassess trust policies when vendors, accounts, applications, or deployment workflows change.

Temporary credentials reduce the need for long-term keys, but they do not eliminate the need to protect the identities that can request them.

============================================================ 11. COMMON MISINTERPRETATIONS

"Temporary credentials are harmless because they expire."

Incorrect. They can still provide meaningful access while valid. Assess their permissions and the resources they can reach.

"If I can see a role ARN, I can assume it."

Incorrect. The caller's authorization, the role trust policy, and applicable conditions must permit the request.

"If AssumeRole succeeds, I have administrator access."

Incorrect. The resulting session's effective permissions depend on the role and other applicable authorization controls.

"A twelve-hour maximum means every session can last twelve hours."

Incorrect. The requested duration must be within the applicable maximum, and role chaining imposes a one-hour maximum for chained sessions.

"A role trust relationship to another account is automatically a vulnerability."

Incorrect. Cross-account access is a normal AWS pattern. The finding depends on whether the trust is unintended or too broad and what access it actually enables.

"A session name proves who performed an action."

Incorrect. Session names are useful metadata, but they can be caller-supplied. Evaluate source identity and the surrounding authentication and logging context.

============================================================ 12. SECURITY RESEARCHER CHECKLIST

Before making a claim about STS or AssumeRole, record:

The starting identity and AWS account context.
The target role ARN and its trust policy.
The exact action or API request under review.
Relevant identity and resource policy statements and conditions.
Any permissions boundaries, session policies, organization controls, or explicit denies that apply.
The role's effective permissions and the resources those permissions cover.
The requested and actual session duration, including whether role chaining is involved.
The role session's source identity, session name, and tags when relevant.
The observed result and evidence, distinguishing observed facts from inference.
The realistic impact and the remediation that addresses the underlying cause.
Whether the test was performed within the scope of authorization.

Do not report a theoretical chain as a demonstrated exploit. Explain the preconditions that make the chain possible and which steps were actually observed.

============================================================ FINAL TAKEAWAY

AWS STS provides temporary credentials that let authorized users, applications, and federated identities access AWS resources without relying on long-lived credentials for every task. AssumeRole is a central mechanism for creating role sessions, but a successful request is only one part of the security story.

A sound review traces the complete path: the starting identity, authorization to request the session, the target role's trust policy, the resulting session's effective permissions, session duration and chaining behavior, and the impact of the actions that follow.

The most important distinction is this: temporary credentials are a mechanism for controlled access, not proof that access is safe. Their security depends on who can obtain them, what they can do, how long they last, and whether their use can be detected and attributed.

============================================================ RESEARCH / TECHNICAL NOTE

This article was prepared using AWS documentation. It does not claim personal testing, a live AWS assessment, or observed lab output.

Primary AWS sources:

AWS STS API Reference — AssumeRole https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html
AWS IAM User Guide — Request temporary security credentials https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html
AWS IAM User Guide — Temporary security credentials https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html
AWS IAM User Guide — Pass session tags in AWS STS https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html
AWS IAM User Guide — Logging IAM and AWS STS API calls with CloudTrail https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html
AWS IAM User Guide — Permissions for temporary security credentials https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access.html
AWS IAM User Guide — Policy evaluation logic for resource-based policies, session policies, and role sessions https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic_policy-eval-denyallow.html