Why AssumeRole Beats GetSessionToken: Deep Dive into AWS IAM Security

Understanding GetSessionToken vs AssumeRole

Both GetSessionToken and AssumeRole exchange long‑lived credentials for short‑lived ones, but they differ dramatically in security model. GetSessionToken returns temporary credentials that retain the original user’s permissions (A, B, C) for a limited time, essentially acting as a time‑boxed version of the same identity. AssumeRole creates a new temporary identity that borrows a specific role’s permissions (for example, a read‑only database‑admin role D) while discarding the caller’s original privileges during the session. This “borrower” model isolates the actions to the role’s scope.

Security Model Shift: Holder to Borrower

The article uses a building‑access analogy: the IAM user is a master key that can open every door, but with AssumeRole you lock the master key in a safe and borrow a guest card that only opens the 22nd‑floor office. The guest card expires automatically, enforcing least‑privilege access.

Benefits of AssumeRole

Privilege De‑escalation – Even administrators can assume a low‑privilege role for routine checks, adhering to the principle of least privilege.

Separation of Duties – Identity (user) and permissions (role) are decoupled, allowing fine‑grained “work‑hats” to be applied on demand.

Audit Granularity – CloudTrail logs record events such as [YourUser] assumed role [DeveloperRole]. Subsequent actions are attributed to [DeveloperRole], providing clear audit trails.

Role Visibility: Can a User List Assumeable Roles?

Ordinarily, a standard IAM user cannot retrieve a list of roles they are allowed to assume with a single API call because the trust relationship is one‑way: a role’s trust policy names the principals it trusts, but the principal does not have a reverse pointer.

However, a user with sufficient IAM permissions can discover assumable roles by enumerating them:

Call iam:ListRoles to obtain all roles in the account.

For each role, call iam:GetRole to fetch its trust policy.

Parse the JSON trust policy and check whether the Principal field contains the user’s ARN.

Strengthening Trust Policies

The real security barrier in AssumeRole is the role’s trust policy, which acts as a strict gatekeeper. Even if an attacker discovers many roles, they cannot assume any role whose trust policy does not explicitly allow their identity.

Enforce MFA – Add "aws:MultiFactorAuthPresent": "true" to require multi‑factor authentication.

Restrict Source IP – Use "aws::SourceIp": "203.0.113.0/24" to limit calls to trusted networks.

Time‑window Constraints – Allow role assumption only during business hours on weekdays.

Conclusion

AssumeRole is more than a workaround – It elevates security from “identity equals permissions” to “identity borrows permissions,” delivering least‑privilege, separation of duties, and fine‑grained audit.

Roles are not inherently discoverable – Regular users cannot list assumable roles directly, adding a layer of obscurity.

True security does not rely on hidden roles – With enough IAM permissions, an adversary can enumerate roles, so defenses must focus on explicit trust‑policy controls.

Trust policies are the immutable barrier – Properly crafted policies, combined with MFA, IP restrictions, and time windows, create a robust, zero‑trust‑aligned defense even if role information is exposed.