L2. Federation & Cross-Account Access: STS, SAML/OIDC & AssumeRole

Why Temporary Credentials Exist

AWS Security Token Service (STS) issues short-lived credentials so that identities don't need to carry long-lived IAM user access keys around. Temporary credentials expire on their own, which shrinks the blast radius if they are ever leaked, and they eliminate the need to rotate secrets manually. The exam expects you to recognize STS as the mechanism underneath almost every federation and cross-account access pattern.

The Three Core STS APIs

• AssumeRole: used when an existing IAM principal, in the same account or a different one, needs to take on the permissions of an IAM role. This is the backbone of cross-account access.
• AssumeRoleWithSAML: used for enterprise SSO federation, where a corporate identity provider (such as Active Directory Federation Services) issues a SAML 2.0 assertion that AWS trusts.
• AssumeRoleWithWebIdentity: used for OIDC federation, where an external identity provider issues a JSON Web Token. Common examples include Amazon Cognito for mobile and web apps, and CI/CD systems like GitHub Actions authenticating to AWS without ever storing a long-lived access key.

Two Policies, Two Gatekeepers

Every IAM role has two distinct policies that must both cooperate:

1. A trust policy, which defines who is allowed to assume the role.
2. A permissions policy, which defines what the role can do once assumed.

For an assumption to succeed, the caller needs sts:AssumeRole permission in their own identity-based policy, and the role's trust policy must explicitly list that caller's principal. Missing either side causes the assumption to fail. This dual-gatekeeper design is a frequent exam scenario.

Preventing the Confused Deputy Problem

When a trust policy grants a third party (like a SaaS vendor or auditor) the ability to assume a role in your account, always add an sts:ExternalId condition. Without it, an attacker who convinces the third party to act on their behalf (using the third party's own legitimate, valid permissions) could trick that party into assuming your role and acting maliciously. The ExternalId is a shared secret between you and the third party that closes this gap.

Centralizing Human Access

For human users across a large AWS Organization, hand-rolling per-account IAM roles doesn't scale. IAM Identity Center (formerly AWS SSO) centralizes federated access using permission sets, which are templates of permissions assigned to users or groups across many accounts from a single place. This is the recommended approach for workforce access at scale, versus building custom SAML federation into every individual account.

Exam tip: Role session duration is configurable per role, up to a maximum of 12 hours by default. This is why STS-based access is consistently favored over long-lived IAM user access keys for anything beyond a legacy workload that truly cannot use roles.