Identity Federation

Identity Federation lets users from outside AWS (corporate Active Directory, Google, Okta, GitHub) access AWS resources without creating individual IAM users. Instead, external identities are mapped to IAM roles via federation protocols.

Federation Methods

• IAM Identity Center (SSO): AWS recommended; centralized access management for multiple accounts with built-in user portal
• SAML 2.0: for enterprise identity providers (Active Directory, Okta, OneLogin)
• OIDC (OpenID Connect): for web/mobile apps and CI/CD (GitHub Actions, GitLab, EKS pod identity)
• Amazon Cognito: for customer-facing applications with social login

How Federation Actually Flows

Whatever the protocol, the shape is the same. The external identity provider authenticates the user or workload and issues a signed assertion (SAML response) or token (OIDC JWT). That artifact is presented to AWS STS, which validates the signature against the provider you registered in IAM, checks the role's trust policy conditions, and returns ordinary temporary credentials for the mapped IAM role. AWS never sees a password; trust is anchored in two places you control: the IdP registration in IAM and the trust policy on each role. That also means those two objects are your attack surface. The SAML response size limit for the STS AssumeRoleWithSAML call is 100,000 characters base64 encoded, worth knowing when groups bloat enterprise assertions.

For machine identities, OIDC federation has largely replaced static keys: a GitHub Actions workflow, for example, presents its short-lived OIDC token to STS and assumes a deploy role, with the trust policy pinning the repository and branch claims. No secret exists to leak.

How It Goes Wrong in Practice

The best documented failure is the under-constrained OIDC trust policy. When teams wire GitHub Actions (or any CI system) to AWS, the role trust policy must validate the token's audience and, critically, the subject claim identifying the repository. A trust policy that checks only the provider, or uses a wildcard subject like repo:myorg/* too broadly (or worse, omits the condition entirely), allows any workflow from any matching repository, in some misconfigurations any GitHub user at all, to assume the role. Security researchers have repeatedly found production AWS roles assumable from arbitrary public repositories because of exactly this. Pin the sub claim to specific repositories and branches, and treat the trust policy like the credential it is.

On the SAML side, the recurring issue is the forgotten IdP. Federation concentrates access in the IdP, so a stale SAML provider left registered after a vendor migration, or weak admin controls at the IdP itself, hands over every role that trusts it. Anyone who can control assertions from a trusted IdP controls the mapped roles; audit registered providers with the same seriousness as IAM admin users.

Practical Check: Inventory Your Trusted Providers

List every identity provider your account trusts, both protocols:

aws iam list-saml-providers

aws iam list-open-id-connect-providers

Neither command takes required parameters. The SAML listing returns each provider's ARN plus ValidUntil and CreateDate; the OIDC listing returns provider ARNs. Every entry should map to a system you recognize and still use; anything else is standing attack surface to remove. Then check which roles trust each provider by reading their trust policies (aws iam get-role shows the AssumeRolePolicyDocument), paying attention to the condition block: that is where audience and subject pinning lives.

Frequently Asked Questions

Should I use IAM SAML/OIDC federation or IAM Identity Center?

For workforce access to AWS accounts, Identity Center: it manages the federation, role provisioning, and portal experience for you across an organization. Direct IAM federation remains the right tool for workload identity (CI/CD via OIDC, EKS pods) and for customer-facing apps you should look at Cognito.

Does federation remove the need for IAM roles?

No, the opposite: every federated identity ends up in an IAM role. Federation replaces long-term credentials and user directories, not authorization. Least privilege still happens in the role's permission policies, and session duration is governed by the role's maximum session duration setting.

What is the maximum session length for a federated role session?

Role sessions are bounded by the role's maximum session duration setting, which can be configured between 1 and 12 hours; requests specify a duration from 900 seconds up to that cap, and default to one hour when unspecified. Keep CI/CD sessions short, since the whole point of workload federation is minimizing how long any credential stays useful.