SAML, OIDC, and Web Identity Federation

Federation lets identities defined outside AWS sign in and receive AWS permissions without ever having an IAM user.

An external identity provider (IdP) vouches for the user, and AWS trusts that assertion to issue temporary credentials. This avoids duplicating accounts and keeps the source of truth in your existing directory.

SAML (Security Assertion Markup Language) 2.0 is the classic standard for enterprise federation.

• You register the IdP in IAM as a SAML identity provider.
• The IdP sends a signed assertion after the user logs in.
• AWS exchanges it via STS for temporary role credentials.

It is common with Active Directory Federation Services and similar corporate IdPs.

OIDC (OpenID Connect) is a modern token-based standard built on OAuth 2.0.

It is ideal for federating workloads and CI/CD systems. For example, a GitHub Actions pipeline can present an OIDC token, and AWS assumes a role with no stored keys. You register the provider as an IAM OIDC identity provider.

Web identity federation lets users sign in with a public provider such as Google, Facebook, or Amazon, common in mobile and web apps.

The app passes the provider's token to STS via AssumeRoleWithWebIdentity, receiving temporary credentials scoped to a role. Users never need an IAM identity.

All federation paths converge on STS (Security Token Service). STS exchanges a verified external assertion for short-lived AWS credentials tied to an IAM role.

• SAML uses AssumeRoleWithSAML.
• OIDC and web identity use AssumeRoleWithWebIdentity.

The role's permissions define what the federated user can do.

The IAM role a federated user assumes has a trust policy naming the IdP as the principal.

Conditions in the trust policy restrict who from that provider may assume the role, for example matching a specific SAML attribute or an OIDC sub claim. This keeps a broad provider from granting access to everyone.

IAM Identity Center is itself a federation layer for the workforce, with a polished portal and permission sets.

Raw IAM SAML or OIDC providers are lower-level building blocks better suited to application and workload federation or legacy setups. The exam expects you to pick Identity Center for human SSO and OIDC roles for pipelines.

For consumer-facing apps, Amazon Cognito identity pools brokers web identity federation for you.

It exchanges social or user-pool logins for temporary AWS credentials, handling the STS calls behind the scenes. This is the recommended path for mobile apps rather than calling AssumeRoleWithWebIdentity directly.

The whole point of federation is to stop embedding long-term keys in apps, pipelines, and devices.

• Leaked static keys are a top breach cause.
• Federated tokens are short-lived and tied to a verified identity.

If you see hardcoded access keys in a scenario, federation is usually the fix.

Match the standard to the source:

• SAML for traditional enterprise IdPs and AD.
• OIDC for modern workloads and CI/CD.
• Web identity / Cognito for public app users.

All deliver temporary credentials, differing mainly in token format and use case.

Federated sessions appear in CloudTrail with the assumed-role identity and the federation event.

You can trace which IdP and which external user triggered an action, preserving accountability even though no IAM user exists. Consistent role naming makes these logs far easier to read.

Pick the right federation choice.

You compared the federation standards.

• SAML for enterprise IdPs, OIDC for workloads, web identity/Cognito for app users.
• All exchange a verified external assertion via STS for temporary role credentials.
• Federation removes the need for embedded long-term keys.